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Preface 



This volume contains the proceedings of the 11th International Conference on 
Concurrency Theory (CONCUR 2000) held in State College, Pennsylvania, USA, 
during 22-25 August 2000. 

The purpose of the CONCUR conferences is to bring together researchers, 
developers, and students in order to advance the theory of concurrency and 
promote its applications. Interest in this topic is continuously growing, as a 
consequence of the importance and ubiquity of concurrent systems and their ap- 
plications, and of the scientific relevance of their foundations. The scope covers 
all areas of semantics, logics, and verification techniques for concurrent systems. 
Topics include concurrency related aspects of: models of computation, semantic 
domains, process algebras, Petri nets, event structures, real-time systems, hybrid 
systems, decidability, model-checking, verification techniques, refinement tech- 
niques, term and graph rewriting, distributed programming, logic constraint pro- 
gramming, object-oriented programming, typing systems and algorithms, case 
studies, tools, and environments for programming and verification. 

The first two CONCUR conferences were held in Amsterdam (NL) in 1990 
and 1991. The following ones in Stony Brook (USA), Hildesheim (D), Uppsala 
(S), Philadelphia (USA), Pisa (I), Warsaw (PL), Nice (F), and Eindhoven (NL). 
The proceedings have appeared in Springer LNCS, as Volumes 458, 527, 630, 
715, 836, 962, 1119, 1243, 1466, and 1664. 

Of the 72 regular papers submitted this year, 34 were accepted for presen- 
tation and are included in the present volume. The conference included also 
talks by four invited speakers: Ed Brinksma (Universiteit Twente, NL), Alberto 
Sangiovanni-Vincentelli (UC at Berkeley, USA), Natarajan Shankar (SRI Inter- 
national, USA), and Eugene Stark (SUNY at Stony Brook, USA). Additionally, 
there were four invited tutorials by Rajeev Alur (University of Pennsylvania, 
USA), Rocco De Nicola (Universita di Firenze, I), Philippa Gardner (University 
of Cambridge, UK), and C. R. Ramakrishnan (SUNY at Stony Brook, USA). 
The conference had four satellite events: 

— EXPRESS’OO (7th International Workshop on Expressiveness in Concur- 
rency), organized by Luca Aceto and Bjorn Victor, held on 21 August 2000. 

— GETCO 2000 (2nd Workshop on Geometric and Topological Methods in 
Concurrency Theory), organized by Eric Goubault, Maurice Herlihy, and 
Martin Raussen, held on 21 August 2000. 

— YOO (Why Object-Orientation) organized by Arend Rensink, held on 26 
August 2000. 

— MTCS 2000 (First Workshop on Models for Time-Critical Systems) orga- 
nized by Flavio Corradini and Paola Inverardi, held on 26 August 2000. 

I would like to thank my conference co-chair. Dale Miller, the members of the 
program committee and their subreferees, the workshop chair, Uwe Nestmann, 
and the workshop organizers. I also would like to thank the invited speakers and 
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invited tutorial speakers, the authors of submitted papers, and all the partici- 
pants of the conference. Special thanks go to Vladimiro Sassone for providing 
the software that helped to handle the submissions and the electronic PC meet- 
ing. Finally, I would like to thank the Department of Computer Science and 
Engineering of the Pennsylvania State University for sponsoring the event and 
providing many facilities. 

I also would like to express all my gratitude and love to my husband Dale 
Miller and to our baby daughter, Nadia Alexandra Miller, for their patience with 
a wife and mom who was even busier than usual. 
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Combining Theorem Proving and Model 
Checking through Symbolic Analysis* 



Natarajan Shankar 

Computer Science Laboratory, SRI International 
Menlo Park CA 94025 USA 
Phone: +1 (650) 859-5272 
shankarOcsl . sri . com 
http : //www. csl . sri . com/~shankar/ 



Abstract. Automated verification of concurrent systems is hindered by 
the fact that the state spaces are either infinite or too large for model 
checking, and the case analysis usually defeats theorem proving. Com- 
binations of the two techniques have been tried with varying degrees 
of success. We argue for a specific combination where theorem proving 
is used to reduce verihcation problems to hnite-state form, and model 
checking is used to explore properties of these reductions. This decom- 
position of the verihcation task forms the basis of the Symbolic Analysis 
Laboratory (SAL), a framework for combining different analysis tools for 
transition systems via a common intermediate language. We demonstrate 
how symbolic analysis can be an effective methodology for combining de- 
duction and exploration.^ 



The verification of large-scale concurrent systems poses a difficult challenge 
in spite of the substantial recent progress in computer-aided verification. Tech- 
nologies based on model checking [CGP99] can typically handle systems with 
states that are no larger than about a hundred bits. Techniques such as symme- 
try and partial-order reductions, partitioned transition relations, infinite-state 
model checking, represent important advances toward ameliorating state explo- 
sion, but they have not dramatically increased the overall effectiveness of au- 
tomated verification. Model checking does have one advantage: it needs only a 
modest amount of human guidance in terms of the problem description, possi- 
ble variable orderings, and manually guided abstractions. Verification based on 
theorem proving, on the other hand, requires careful human control by way of 
suitable intermediate assertions, invariants, lemmas, and proofs. Can automated 
verification ever combine the automation of model checking with the generality 
of theorem proving? 

It has often been argued that model checking and theorem proving could be 
combined so that the former is applied to control-intensive properties while the 

* This work was funded by DARPA Contract No. F30602-96-C-0204 Order No. D855 
and NSF Grants No. CCR-9712383 and CCR-9509931. 

^ The SAL project is a collaborative effort between Stanford University, SRI Inter- 
national, and the University of California, Berkeley. 
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latter is invoked on data-intensive properties. Achieving an integration of theo- 
rem proving and model checking is not hard. Both techniques verify claims that 
look similar and it is possible to view model checking as a decision procedure for 
a well-defined fragment of a specification logic [RSS95]. However, most systems 
contain a rich interaction between control and data so that there is no simple 
decomposition between data-intensive and control-intensive properties. 

For the purpose of this paper, we view model checking as a technique for 
the verification of temporal properties of a program based on the exhaustive ex- 
ploration of a transition graph represented in explicit or symbolic form. Model 
checking methods typically use graph algorithms, automata-theoretic construc- 
tions, or finite fixed point computations. Theorem proving is usually based on 
formalisms such as first-order or higher-order logic, and employs proof techniques 
such as induction, rewriting, simplification, and the use of decision procedures. 
Some infinite-state verifiers and semi-decision procedures can be classified as 
both deductive and model checking techniques, but this ambiguity can be over- 
looked for the present discussion. 

We make several points regarding the use of theorem proving and model 
checking in the automated verification of concurrent systems: 

1. Correctness is over-rated. The objective of verification is analysis, i.e., the 
accretion of useful observations regarding a system. Verifying correctness is 
an important form of analysis, but correctness is usually a big property of 
a system that is demonstrated by building on lots of small observations. If 
these small observations could be cheaply obtained, then the demonstration 
of larger properties would also be greatly simplified. The main drawback of 
correctness is its exactitude. The verification of a correctness claim can only 
either fail or succeed. There is no room for approximate answers or partial 
information. 

2. Theorem proving is under-rated. Deduction remains the most appropriate 
technology for obtaining insightful, general, and reusable automation in the 
analysis of systems, particularly those that are too complex to be analyzed 
by a blunt instrument like model checking. Theorem proving can exploit the 
mathematical properties of the control and data structures underlying an 
algorithm in their fullest generality and abstractness 

3. Theorem proving and model checking are very similar techniques. In the ver- 
ification of transition systems, both techniques employ some representation 
for program assertions, they compute the image of the transition relation 
with respect to these assertions, and usually try to compute the least, great- 
est, or some intermediate fixed point assertion for the transition relation. 
The difference is that in theorem proving, 

— The image constructions are usually more complicated since they involve 
quantification in domains where quantifier elimination is either costly or 
impossible. 

— The least and greatest fixed points can seldom be effectively computed 
and human guidance is needed to suggest an intermediate fixed point. 

— Showing that one assertion is the consequence of another is typically 
undecidable and requires the use of lemmas and human insight. 
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4. Theorem proving and model checking can he usefully integrated. Such an 
integration requires a methodology that decomposes the verification task so 
that 

— Deduction is used to construct valid finite-state abstractions of a system. 
The construction of a property-preserving abstraction generates simple 
proof obligations that can be discharged, often fully automatically, using 
a theorem prover. These are typically assertions of the form: if property p 
holds in a state s from which there is a transition i? to a state s', then 
property q holds in s' . Similar proof obligations arise during verification 
(in the form of verification conditions) but these are usually not valid 
and the assertions have to be strengthened in order to obtain provable 
verification conditions. While theorem proving is useful for examining 
the local consequence of properties, it is not very effective at deducing 
global consequences over a large program or around an iterative loop. 
Such computations can be extremely inefficient and the computation of 
fixed points around a loop rarely terminates. 

— Exploration by means of model checking is used to calculate global prop- 
erties of such abstractions. This means that model checking is not used 
merely to validate or refute putative properties but is actually used to 
calculate interesting invariants that can be extracted from the reacha- 
bility predicate or its approximations. Finite-state exploration of large 
structures can also be inefficient but it is much easier to make finite-state 
computations converge efficiently. 

— Deduction is used to propagate the consequences of such properties. For 
example, model checking on a finite-state abstraction might reveal an 
assertion a; > 5 to hold at a program point simply because it was true 
initially and none of the intermediate transitions affected the value of x. 
If the program point has a successor state that can only be reached by a 
transition that increments a; by 2, then we know that this successor state 
must satisfy the assertion x > 7. Such a consequence is easily deduced 
by theorem proving. 

In summary, we advocate a verification methodology where deduction is em- 
ployed in the local reasoning steps such as validating abstractions and propagat- 
ing known properties, whereas model checking is used for deriving global con- 
sequences. In contrast, early attempts to integrate theorem proving and model 
checking were directed at using model checking as a decision procedure within 
a theorem prover. These attempts were not all that successful because it is not 
common to find finite-state subgoals within an infinite-state deductive verifica- 
tion. 



1 Background 

We review some of the background and previous work in the combined use of 
theorem proving and model checking techniques. 



4 



Natarajan Shankar 



1.1 Model Checking as a Decision Procedure 

Joyce and Seger combined the theorem prover HOL [GM93] with the symbolic 
trajectory evaluation tool Voss [JS93] by treating the circuits verified by Voss 
as uninterpreted constants in HOL. This integration is somewhat ad hoc since 
the definitions of the circuits verified by Voss are not available to HOL. Dingel 
and Filkorn [DF95] use a model checker to establish assume-guarantee proper- 
ties of components and a theorem prover to discharge the proof obligations that 
arise when two components are composed. Rajan, Shankar, and Srivas [RSS95] 
integrate a mu-calculus [Par76,BCM'*'92] model checker [.Jaii93] as a decision 
procedure for a fragment of the PVS higher-order logic corresponding to a fi- 
nite mu-calculus. While this integration smoothly incorporates CTL and LTL 
model checking into PVS, the work needed to reduce a problem into model- 
checkable form can be substantial. This integration has recently been extended 
with an algorithm for constructing finite-state abstractions of mu-calculus ex- 
pressions [SS99].^ 

1.2 Extending Model Checking with Lightweight Theorem Proving 

Several alternative approaches to the integration of model checking and theorem 
proving have emerged in recent years. Some of these have taken the approach of 
supplementing a model checker with a proof assistant that provides rules for de- 
composing a verification goal into model-checkable subgoals. McMillan [McM99] 
in his work with Cadence SMV has extended the SMV model checker with the 
following decomposition rules that are used to reduce infinite-state systems to 
model-checkable finite-state ones. 

1. Temporal splitting: Transforms a goal of the form □(Vi : A) into □?; = i D A 
for each i. 

2. Symmetry reduction: Typically, the system being verified and the property 
are symmetric in the choice of i so that proving Gw = i D A for a sin- 
gle specific value for i is equivalent to proving it for each i. Examples of 
such symmetric choices include the memory address or the processor in the 
verification of multiprocessor cache consistency. 

3. Data abstraction: Large or infinite datatypes can be reduced to small finite 
datatypes by suitably reinterpreting the operations on these datatypes. For 
example, with respect to the choice of i in temporal splitting, the remaining 
values of the datatype can be abstracted by a single value non-i. 

4. Compositional verification: The verification oi P\\Q \= A A B is decomposed 
as P 1= U ^A) {B fails before A does) and Q \= ~^{A U ^B). This 
allows different components to be separately verified up to time t -I- 1 by 
assuming the other components to be correct up to time t. 

These and other proof techniques have been used to verify an out-of-order 
processor, a large cache coherence algorithm, and safety and liveness for a ver- 
sion of Lamport’s N-process bakery algorithm for mutual exclusion [MQSOO]. 

These features are part of PVS 2.3 which is accessible at the URL pvs . csl . sri . com. 



2 



Combining Theorem Proving and Model Checking 



5 



McMillan’s approach is substantially deductive. The rules of inference, such as 
symmetry reduction and compositional verification, are specialized but quite 
powerful. 

Seger [Seg98] has extended the Voss tool for symbolic trajectory evaluation 
with lightweight theorem proving. Symbolic trajectory evaluation (STE) which is 
a limited form of linear temporal logic model checking. A few simple proof rules 
are used to decompose proof obligations on the basis of the logical connectives 
such as conjunction, disjunction, and implication. These rules can be used to 
decompose a large model checking problem into smaller ones. 

1.3 Abstraction and Model Checking 

Abstraction has been studied in the context of model checking as a technique 
for reducing infinite-state or large finite-state models to finite-state models of 
manageable size [BBLS92,Kur94,CGL94,LGS“''95,Dam96,BL098]. 

Some of the work on abstraction is based on data abstraction where a vari- 
able X over a concrete datatype T is mapped to a variable x over an abstract 
type t. For example, a variable over the natural numbers could be replaced by 
a boolean variable representing the parity of its value. Glarke, Grumberg, and 
Long [GGL94] gave a simple criterion for abstractions that preserve VCTL*+ 
properties. Let the concrete transition system be given by (Ic,Nc) where Iq is 
the initialization predicate and Nc is the next-state relation. Then the verifica- 
tion of a concrete judgement (/c, Nc) H Pc can be reduced by means of the ab- 
straction function a to the verification of an abstract judgement {I a, Na) ^ Pa 
provided 

1 - Ic QIa°C( 

2 . Nc E Na o (a, a) 

3. Pa o o E Pc 

Data abstraction has the advantage that the abstract description can be 
statically constructed from the concrete program. The drawback is that many 
useful abstractions are on relations between variables rather than on individual 
variables. 

Graf and Sai'di [SG97] introduced predicate abstraction as a way of replac- 
ing predicates or relations over a set of variables by the corresponding boolean 
variables. For example, given two variables x and y over the integers, and the 
predicate x < y over these variables, predicate abstraction would replace the 
variables x and y by a boolean variable b that represents the behavior of the 
predicate. 

The application of predicate abstraction makes significant use of theorem 
proving. Graf and Sai'di used predicate abstraction to construct an abstract 
reachability graph for a concrete program by a process of elimination. If a rep- 
resent an abstract state, a' a putative successor, j(a) the concrete state corre- 
sponding to a, and 7 ( 0 ') the concrete state corresponding to a', then if 



7 (a) D wp(P)(^( 7 (a'))) 
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is provable, the corresponding transition between a and a' can be ruled out.^ 
However, if a proof attempt fails, the corresponding successor node can be con- 
servatively included in the abstract reachability graph. Using predicate abstrac- 
tions with the PVS theorem prover [ORS92], Graf and Sa'idi [SG97] were able to 
verify a variant of the alternating bit protocol called the bounded retransmission 
protocol [HSV94]. Das, Dill, and Park [DDP99] extended this technique using 
the SVG decision procedures [BDL96] and were able to verify such impressive 
examples as the FLASH cache coherence protocol, and a cooperative garbage 
collector. 

Predicate abstraction can also be used to construct an abstract transition 
relation instead of the abstract reachability graph. It is typically less expen- 
sive to construct the abstract transition relation since fewer proof obligations 
are generated, but it typically results in a coarser abstraction than one that 
is obtained by directly computing the abstract reachability graph. In the lat- 
ter construction, information about the current set of abstract reachable states 
can be used to rule out unreachable successor states. Bensalem, Lakhnech, and 
Owre [BL098] describe an abstraction tool called InVeSt that uses the elimi- 
nation method to construct an abstract transition system from a concrete one 
in a compositional manner. Golon and Uribe [GU98] give another compositional 
method for constructing abstractions with the framework of the STeP theorem 
prover [MtSG95]. 

All of the above abstraction techniques preserve only VC'TL*+ proper- 
ties, namely those in the positive fragment of CTL* with universal path 
quantification. For more general calculi, criteria for abstractions that preserve 
GTL* [DGG94] and mu-calculus [LGS+95], but these results are quite technical. 
Sa’idi and Shankar [SS99] gave a simple method for constructing predicate ab- 
stractions over the full relational mu-calculus [Par76]. The two key observations 
in this work are: 

1. The operators of the mu-calculus are monotonic with respect to upper and 
lower approximations. 

2. The over-approximation of a literal (an atomic formula or its negation) can 
be efficiently computed in conjunctive normal form by using a theorem prover 
as an oracle. 

Verification diagrams [MBSU99] can also be seen as a form of predicate ab- 
straction. These diagrams employ graphs whose nodes are labeled by assertions 
and the edges correspond to program transitions within the diagram. Properties 
can be directly checked with respect to the verification diagram. 

The primary advantage of predicate abstraction is that it is sufficient to 
guess a relevant predicates without having to guess the exact invariant in these 
predicates. For n predicates, the construction of the abstract transition system 

® All programs are assumed to be total as transition system, i.e., the domain of the 
next-state relation is the set of all states. Thus, wp{P){A) is the set of states that 
have no transitions in P to states in -lA. The dual notion sp{P){A) is the set of 
states reachable from some state in A by a transition of P. 
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generates of the order of 2” proof obligations. The resulting abstract model can 
also be model checked in time that is exponential in n to yield useful invariants. 
With deduction, there are 2^ boolean functions that are candidate invariants 
in these n predicates so that it is harder to guess suitable invariants. 

1.4 Automatic Invariant Generation 

Automatic invariant generation has been studied since the 
1970s [CH78,GW75,KM76,SI77]. This study has recently been revived 
through the work of Bjprner, Browne, and Manna [BBM97], and Bensalem, 
Lakhnech, and Saidi [BLS96,Sai'96,BL99]. 

The strongest invariant of a transition system P is given by the least fixed 
point starting from the initial states of P of the strongest postcondition operator 
for P, fxX.Ip V sp{P){X). If this computation terminates, it would yield the set 
of reachable states of P which is its strongest invariant. Unfortunately, the least 
fixed point computation rarely terminates for infinite-state systems. A program 
with a single integer variable x that is initially 0 and is repeatedly incremented 
by one, yields a nonterminating least fixed point computation. Widening tech- 
niques [CC77] are needed to accelerate the fixed point computation so that it 
does terminate with a fixed point that is not necessarily the least one. 

A different, more conservative approach to invariant generation is given 
by the computation of the greatest fixed point of the strongest postcondition 
uX.sp{P){X). For example, a greatest fixed point computation on a program 
with a single variable x and a single guarded transition x > 0 — > x := x + 1 
would terminate and yield the invariant a; > 0. The greatest fixed point invari- 
ant computation also may not terminate and could require narrowing as a way 
of accelerating termination. However, one could stop the greatest fixed point 
computation after any bounded number of iterations and the resulting predicate 
would always be a valid invariant. 

Dually, a putative invariant p can be strengthened to an inductive one by 
computing the greatest fixed point with respect to the weakest precondition 
of the program of the given invariant pX.p A wp(P)(X). If this computation 
terminates, the result is an invariant that is inductive. 

Automatic invariant generation is not yet a successful technology. Right now, 
it is best used for propagating invariants that are computed from other sources 
by taking the greatest fixed point with respect to the strongest post-condition 
starting from a known invariant. However, as theorem proving technology be- 
comes more powerful and efficient, invariant generation is likely to be quite a 
fruitful technique. 

2 Symbolic Analysis 

Symbolic analysis is simply the computation of fixed point properties of programs 
through a combination of deductive and explorative techniques. We have already 
seen the key elements of symbolic analysis as 
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1. Automated deduction, in computing property preserving abstractions and 
propagating the consequences of known properties. 

2. Model checking, as a means of computing global properties of by means of 
systematic symbolic exploration. For this purpose, model checking is used for 
actually computing fixed points such as the reachable state set, in addition 
to verifying given temporal properties. 

3. Invariant generation, as a technique for computing useful properties and 
propagating known properties. 

2.1 SAL: A Symbolic Analysis Laboratory 

SAL is a framework for integrating different symbolic analysis techniques in- 
cluding theorem proving and model checking. The core of SAL is a description 
language for transition systems. The design of this intermediate language has 
been influenced by SMV [McM93], UNITY [CM88], Murphi [MD93], and Reac- 
tive Modules [AH96]. Transition systems described in SAL consist of modules 
with input, output, global, and local variables. Initializations and transitions 
can be either specified by definitions of the form variable = expression or by 
guarded commands. The assignment part of a guarded command consists of as- 
signments of the form x' = expression, meaning the new value of x is the value 
of the expression, as well as selections x' € set, meaning the new value of x 
is nondeterministically selected from the value of the nonempty set set. SAL is 
a synchronous language in the spirit of Esterel [BG92], Lustre [HCRP91], and 
Reactive Modules [AH96], in the sense that transitions can depend on latched 
values as well as current inputs. SAL modules can be composed by means of 

1. Binary synchronous composition P\\Q whose transitions consist of lock-step 
parallel transitions of P and Q. 

2. Binary asynchronous composition P \\Q whose transitions are the interleav- 
ing of those of P and Q. 

3. N-fold synchronous composition (|| (i) : P[i]) 

4. N-fold asynchronous composition ([] (i) : P\i]) 

The implementation of SAL is still ongoing. The version to be released some 
time in 2000 will consist of a parser, typechecker, translators to SMV and PVS, 
a translator to Java (for animation), and a translator from Verilog, among other 
tools. 

Since the SAL implementation is still incomplete, we informally describe some 
examples that motivate the need for a symbolic analysis framework integrating 
abstraction, invariant generation, theorem proving, and model checking. 

2.2 Analysis of a Two Process Mutual Exclusion Algorithm 

As a first example, we use a simplified 2-process version of Lamport’s Bakery al- 
gorithm for mutual exclusion [Lani74]. The algorithm consists of two processes P 
and Q with control variables pep and pcq, respectively, and shared variables x 
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and y. The control states of these processes are either sleeping, trying, or 
critical. Initially, pep and pcq are both set to sleeping and the control vari- 
ables satisfy x = y = 0. The transitions for P are 

pep = sleeping — > x' = y + 1; pep' = trying 

[] pep = trying A {y = 0\/ x < y) > pep' = critical 

[] pep = critical > x' = 0; pep' = sleeping 

Similarly, the transitions for Q are 

pcq = sleeping > y' = x + 1] pcq' = trying 

[] pcq = trying A{x = Q\J y < x) > pc' = critical 

[] pcq = critical y' = 0; pcq' = sleeping 

The invariant we wish to establish for P []Q is -^{pep = critical A pcq = 
critical. Note that P [] Q is an infinite-state system and in fact the values of 
the variables x and y can increase without bound. We can therefore attempt to 
verify the invariant by means of a property-preserving predicate abstraction to 
a finite-state system. 

The abstraction predicates suggest themselves from the initializations, 
guards, and assignments. We therefore abstract the predicate a; = 0 with the 
boolean variable xq, the predicate y = 0 with the boolean variable yo, and the 
predicate x < y with the boolean variable xy. The resulting abstract system can 
be computed as P' and Q', where in the initial state, xq A yo A ~^xy, and the 
transitions for P' are 

pep = sleeping — > Xq = false; xy' = false; pep' = trying; 

[] pep = trying A (jjo V xy) > pep' = critical; 

[] pep = critical — > x'q = true; xy' G {true, false}; 

pep' = sleeping; 



The transitions for Q' are 

pcq = sleeping — > j/g = false; xy' = true; pcq' = trying; 

[] pcq = trying A (a;o V ~^xy) — > pep' = critical; 

[] pep = critical — > j/g = true; xy' = false; pep' = sleeping; 

Model checking the abstract system P' [] Q' easily verifies the invariant 
-^{pep = critical A pcq = critical). 

The theorem proving needed to construct the abstraction is at a trivial level 
that can be handled automatically by the decision procedures over quantifier- 
free formulas in a combination of theories [RSOO]. Such decision procedures 
are present in systems like PVS [ORS92], ESC [Det96], SVC [BDL96], and 
STeP [MtSG95]. The above example can be verified fully automatically by means 
of the abstract-and-model-check command in PVS [SS99]. 
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2.3 Analysis of an N-Process Mutual Exclusion Algorithm 

We next examine a fictional example, namely, one that has not been mechanically 
verified by us. This example is a simplified form of the N-process Bakery algo- 
rithm due to Lamport [Lam74]. The description below shows a hand-executed 
symbolic analysis. 

In this version of the Bakery algorithm, there are N processes P(0) to 
P{N — 1), with a shared array x of size N over the natural numbers. The logical 
variables i, j, and k range over the subrange 0..(A — 1). The operation max{x) 
returns the maximal element in the array x. Initially, each P{i) is in the control 
state sleeping, and for each i, x{i) = 0. Let (x, i) < {y,j) be defined as the lex- 
icographic ordering x<y\/{x = y/\i<j). We abbreviate y = 0 V (x, i) < (y, j) 
as (x,i) ^ (y, j). 

The transitions of processes P(i) for 0 < f < A are interleaved and each 
non-stuttering transition executes one of the following guarded commands. 

pc{i) = sleeping — > x'{i) = 1-1- max{x); 

pc'{i) = trying; 

[] pc{i) = trying > pc'(i) = critical; 

A (Vj : (x(i),f) ^ (x(j),j)) 

[] pc{i) = critical — > x'(i) = 0; 

pc'(i) = sleeping; 



We want to prove the invariance property 

(Vi : pc{i) = critical D (Vj : pc{j) = critical D i = j)). (1) 

Invariant generation techniques can be used to generate trivial invariants 
such as 

(Vf : x(i) = 0 iff pc{i) = sleeping). (2) 

We omit the details of the invariant generation step. The above invariant will 
prove useful in the next stage of the analysis. 

We next skolemize the mutual exclusion statement so as to obtain a correct- 
ness goal about a specific but arbitrary i which we call a. The main invariant 
now becomes 



pc{a) = critical D (Vj : pc{j) = critical D a = j) (3) 

The goal now is to reduce the A-process protocol to a two process protocol 
consisting of process a and another process b that is an existential abstraction of 
the remaining A — 1 processes. By an existential abstraction, we mean one where 
the A — 1 processes are represented by a single process b such that a transition by 
any of the A — 1 processes is mapped to a corresponding transition of b. In such 
an abstraction, b is in control state critical if any one of the A — 1 processes is 
critical. Otherwise, b is in control state trying if none of the A — 1 processes is 
in the state critical and at least one of them is in its trying state. If none of 
the A — I process is either trying or critical, then b is in its sleeping state. 
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By examining the predicates appearing in the initialization, guards, and the 
property, we can directly obtain the following abstraction predicates given by 
the function 7 which maps abstract variables to the corresponding concrete 
predicates: 

7(pca) = pc{a) 

7(pc6) = if { 3 j : j a f\pc{j) = critical) 
then critical 

elsif { 3 j : j ^aA pc{j) = trying) 
then trying 
else sleeping 

7(2:00) = (x{a) = 0) 

7(2:60) = (Vj ■. j x{j) = 0) 

7(ma) = (Vj : {x{a),a) A {x{j),j)) 

Z{mb) = { 3 j : (V/c : {x{j)J) A {x{k),k)) 

7(ea) = (Vj : pc{j) = critical Z) a = j) 

Since mb is only relevant when pc{j) = trying for j yf a, we can use invari- 
ant (2) to prove that 

j yf a A pc{j) yf sleeping D z{mb) = z{^ma) 

thereby dispensing with mb in the abstraction. 

With the above abstraction mapping, the goal invariant (3) becomes 

pea = critical D ea. 

and the resulting abstracted transition system is one where initially 

pea = sleeping A peb = sleeping A xa^ A 2:60 A ma A ea 

Each non-stuttering step in the computation of the abstract program executes 
one of the guarded commands shown in Figure 1. 

Model checking the abstract protocol fails to verify the invariant 

pea = critical D ea 

as the model checker could generate the following counterexample sequence of 
transitions: 



transition 


pea 


xa 


ma 


ea 


peb 


xb 


initially 


sleeping 


true 


true 


true 


sleeping 


true 


3 


sleeping 


true 


false 


true 


trying 


false 


4 


sleeping 


true 


false 


false 


critical 


false 


1 


trying 


false 


false 


false 


critical 


false 


8 


trying 


false 


true 


false 


critical 


false 


2 


critical 


false 


true 


false 


critical 


false 
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pea = sleeping > 

[] pea — trying A ma — > 

[] pea = critical > 

[] peh = sleeping — > 

[] peh = trying A -ima > 

[] peb = critical — > 

[] peb = critical — > 

[] peh = critical — > 



xa' = false; 
ma' = xh', 
pea' = trying; 
pea' — critical; 
pea' — sleeping; 
ma' = xb; 

ea' = —'{peb = critical); 
xa' = true; 

peb' = trying; xb' = false; 
ma' = -txa 

peb' = critical; ea' = false; 

peh' = sleeping; 

ea' = true; 

ma' = true; 

xb' = true; 

peb' = trying; 

ea' = true; 

ma' e {true, ma}; 

ma' £ {true, ma}; 



Fig. 1. Abstract transitions for the N-process Bakery Algorithm 



An inspection of the counterexample and the abstract model confirms that 
the mutual exclusion invariant would follow if the invariant ->xa A ma D ea were 
to hold. Mapped back in the concrete domain, this corresponds to 

Vi : x{i) yf 0 A (Vj : x{j) = 

0 V {x{i),i) < {x{j),j)) D (Vj : pc{j) = critical D i = j). 
This goal can be generalized as 

(Vi,j : x{i) yf 0A(a;(j) = 0V(a;(i),i)) < {x{j)J) D (pc(j) = critical D i = j)). 
and further rearranged as 

(Vi, j : pc{j) = critical D (x(i) yf 0A(a;(j) = 0V(a;(i),i) < (x{j)J))) D i = j). 

By the invariant (2), we can eliminate the subformula x{j) = 0 and simplify the 
goal to the equivalent formula 

(Vi, j : pc{j) = critical D x{i) = 0 V {x{j),j) < {x{i),i)). 

This can be rearranged as 

(Vj : pc{j) = critical D (Vi : x{i) = 0 V (x{j),j) < (x(i),i))). 

But this is the just the invariant pea = critical D ma which is already implied 
by the abstract model. 
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The safety property is thus verified by using a judicious combination of a 
small amount of theorem proving and model checking. The abstractions were 
suggested by the predicates in the text of the program. Simple invariant gener- 
ation methods were adequate for generating trivial invariants. Theorem proving 
in the context of these invariants could be used to discharge the proof obli- 
gations needed to construct an accurate abstraction of the N-process protocol. 
Abstraction mappings of this sort are quite standard and work for many mu- 
tual exclusion and cache consistency algorithms [Sha97]. The abstract model did 
not discharge the main safety invariant but it was easy to extract the minimal 
condition needed to verify the invariant from the abstract model. A reachability 
analysis of the abstract model delivered enough useful invariants so that a small 
amount of theorem proving could discharge this condition. Neither the model 
checking nor the theorem proving used here is especially difficult. While some 
guidance is needed in selecting lemmas and conjectures, the proofs of these can 
be carried out with substantial automation. 

3 Conclusion 

We have argued that verification technology is best employed as an analysis 
technique to generate properties of specifications and programs rather than as 
a method for establishing the correctness of specific properties. Such a sym- 
bolic analysis framework can employ both theorem proving and model checking 
as appropriate to generate useful abstractions and automatically derive system 
properties. 

Many ideas remain to be explored within the symbolic analysis framework. 
The construction of the symbolic analysis laboratory SAL as an open framework 
will support the exploration of ideas at the interface of theorem proving and 
model checking. 
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Abstract. The formal verification of concurrent systems is usually seen 
as an example par excellence of the application of mathematical methods 
to computer science. Although the practical application of such verifica- 
tion methods will always be limited by the underlying forms of combi- 
natorial explosion, recent years have shown remarkable progress in com- 
puter aided formal verification. They are making formal verification a 
practical proposition for a growing class of real-life applications, and have 
put formal methods on the agenda of industry, in particular in the areas 
where correctness is critical in one sense or another. Paradoxically, the 
results of this progress provide evidence that successful applications of 
formal verification have significant elements that do not fit the paradigm 
of pure mathematical reasoning. In this essay we argue that verification 
is part of an experimental paradigm in at least two senses. We submit 
that this observation has consequences for the ways in which we should 
research and apply formal methods. 



1 A Little History 

The roots of formal verification lie in the observation, which broke ground in the 
nineteen-sixties and -seventies, that software programs can be seen as formal, i.e. 
mathematical objects. This led to extensive studies of formal semantical models 
for programming languages, and the development of (academic) programming 
languages for which nice formal models could be guaranteed to exist. This ac- 
tivity generated a deeper understanding of the structure of computer programs 
and provided the foundations for many of the mathematical tools and models 
that are known as formal methods today. 

In addition to the development of mathematical models that would help to 
give a scientific foundation to programming, this period was also marked by a 
strong methodological interpretation of these achievements that promoted the 
view of programming as an essentially mathematical activity. If programs are 
mathematical objects and specifications of their intended functionality properly 
formalised, then their correctness can be demonstrated by mathematical means. 
Much effort was directed towards the development of programming calculi in 
which the development of programs can be seen as a form of equation solving. 
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The beauty and strength of this vision were so compelling that they domi- 
nated the scientific research agenda for programming for many years. The move- 
ment as such acquired, perhaps inescapably, also some ideological traits, in the 
sense that it was less forgiving of practical programming as practised in industry, 
and the program validation methods used there, most notably testing. The cure 
for the diagnosed software crisis was thought to be found in the education of a 
new generation of academically trained programmers that would introduce the 
mathematical methods of programming into industry. 



Although the mathematical school of programming has thoroughly influenced 
the the study of programming, programming languages, specification, etc., it 
is now generally acknowledged that the mathematical theory of programming 
cannot be applied as was originally envisaged. Many arguments have been put 
forward to explain why it did not or could not work (see e.g. [7]), including cir- 
cumstantial technical, economical, sociological and educational reasons that we 
will not consider here. An intrinsic reason for failure that was initially overlooked, 
is the retrospectively almost obvious fact that in general a correctness proof has 
a complexity proportional to that of the program involved. This causes direct 
problems in scaling up the method to deal with complicated software systems, 
which was, of course, the ultimate goal. Proofs or derivations of such systems 
would be very complicated and therefore susceptible to errors themselves, di- 
rectly undermining the essential contribution of the method. 



The law of conservation of misery has made sure that there are no easy 
solutions to the problem. The term formal methods became commonplace some- 
where in the nineteen-eighties to indicate the assorted formal notations, theories 
and models that had been developed to help specify, implement amd analyse 
software systems. As by then not only sequential, but also concurrent and re- 
active systems could be mathematically described and analysed in terms of el- 
egant mathematical models, a second wave of methodological optimism swept 
through academia and parts of industry. Having at our disposal methods for the 
formal description and manipulation of algorithms, concurrent interaction and 
data, it was believed that the design and the development of a proof of cor- 
rectness of complex systems could be a shared activity, known as correctness by 
design. Moreover, these integral broad spectrum formalisms would be supported 
by powerful software environments to support the design and verification with 
the required precision, thus solving the problem of controlling the precision of 
complicated (or perhaps better: lengthy) formal manipulations. The failure of 
this second formalist attack on the software crisis was again due to many, diverse 
causes. Again there was one important intrinsic reason: the formal objects that 
corresponded to descriptions of (parts of) the systems designs were so large that 
they could no longer be manipulated effectively, not even by software tools. This 
phenomenon became known as the combinatorial explosion, or in the paticular 
case of the explicit manipulation of system states as the state space explosion. 
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2 Computer Aided Verification 

During the past few years formal methods, and in particular formal verification, 
are again drawing the attention of the research community and (parts of) indus- 
try. This time it is not the result of a methodological movement, but the result of 
technological advances and research in the field of computer aided verification. 
For the first time it has proved possible to formally verify parts of nontrivial sys- 
tems with practical consequences. This success in scaling up verification methods 
from toy examples to small-size real-life systems is the first hard evidence that 
the use of formal methods can, under circumstances, be made consistent with 
the requirements of industrial engineering. 

Broadly speaking, computer aided verification can be categorised in two main 
streams: the theorem proving approach, which uses tools to produce completely 
formal proofs of correctness, and the model checking approach, which is basically 
a brute force approach to enumerate and check all reachable states of the system 
under verification. Both approaches can only work on the basis of a model of the 
system under verification. In theorem proving the model is a logical theory char- 
acterising the (relevant) properties of the system. In model checking the model 
must be operational so that systems states can be systematically produced, and 
usually takes the form an abstract program describing some sort of transition 
system. 

Some reasons for the growing success of computer aided verification are: 

1. The technological improvement of the necessary computing equipment. Be- 
cause of the ever increasing performance of systems in terms of speed and 
available memory, computations that were far beyond the possible ten years 
ago are a matter of routine today. 

2. The availability of serious tool environments. Much of the work on such en- 
vironments has needed a considerable time to come to fruition, and effective 
tools start becoming available now. The development of good tools require 
sustained efforts over many years to develop stable architectures and profit 
from accumulating improvements. 

3. The development of techniques to contain the effects of the combinatorial 
explosion. Abstraction techniques are used to strip away information in the 
model that is not relevant for the verification at hand, and lead to a simplifi- 
cation of verification models. Modular and compositional techniques apply a 
divide and conquer strategy to handle complexity by making formal manip- 
ulation local to well-defined parts of the model that are significantly smaller. 
In model checking substantial progress has also been achieved by the use of 
clever data types that allow for compactification, such as BDDs and the use 
hashing techniques. 

Computer aided verification tends to have a rather pragmatic approach. 
What can be achieved depends more on the capacities and limitations of the 
tools that are being used, and less on methodological considerations. Because 
verification problems in their entirety are too large to handle, the process is 
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eclectic and concentrates on the essentials. This means that only crucial parts 
and properties of the system and its requirements, respectively, are formalised 
and verified. In practice this means that computer aided verification process is 
subject to a process of trial and error to determine how much of a system can 
be verified with the available resources. 

As we are still in the early days of computer aided verification the knowledge 
about the effective scope of applications of the different tools and techniques 
is still very limited. Moreover, it appears to be difficult to generalise successful 
applications as we are sometimes confronted be chaotic behaviour, in the sense 
that small changes to a given problem may have big effects on the effectiveness 
of a particular verification technique. 

Because of the substantial investments that must be made for computer aided 
verification for industrial applications, typical examples concern systems whose 
correct functioning is critical in a certain sense. This is not restricted to the 
so-called safety-critical systems, but applies more generally to systems for which 
the abstract or real cost of their malfunctioning is too high. Highly replicated 
systems (partly) implemented in hardware are a case in point. Embedded systems 
in consumer electronics and the automotive industry are good examples, as well 
as the verification of hardware chip designs. 

Summarising, we can say that computer aided verification takes place in a 
context of experimentation. Different techniques are experimented with to in- 
crease the performance of the tools. Models and specifications are experimented 
with to see how much of a given problem can be verified. Typical examples of 
verification are found outside the world of pure software in interaction with more 
traditional engineering disciplines for which experimentation and measurement 
is an established method of quality control. In addition to this general exper- 
imental atmosphere that surrounds practical verification, there is another and 
more essential link between experimentation and verification. 

3 Verification Needs Experimentation 

Verification needs as its basis a formal model of the system that must be veri- 
fied, the so-called verification model. As it plays a crucial role in the verification 
process, it can be said that a verification is as good as its underlying model. 
Obtaining valid verification models, i.e. models that faithfully represent the rel- 
evant properties of the objects they represent, therefore is a cornerstone of the 
verification process. 

One of the strengths of the original paradigm of programs as mathematical 
objects is that a program text is (through its formal semantics) its own formal 
definition. The question of the validity of the formal model w.r.t. the reality of 
the physically executed program can be dealt with as a correctness requirement 
for the compiler (or interpreter) of the programming language. This has the 
advantage that the problem can be adressed and solved in generic terms, and 
the cost of producing a correct compiler can be amortised over all the programs 
that will be compiled. 
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As already indicated earlier, the situation for actual computer aided verifi- 
cations can be radically different. If a complete, formal definition of the system 
under verification is available then it will usually be too big to serve as an effec- 
tive verification model. This means that additional efforts are required to obtain 
smaller models that are valid for the verification task at hand. 

A way to approach this question is to transform the original model into a 
smaller one, and demonstrate the validity of the result by proof or by construc- 
tion. Indeed, the use of proof checkers for this purpose, in combination with 
model checkers for the verification proper, has been suggested as an elegant way 
to combine the strength of these two verification methods. Although this can be 
useful approach for specific classes of systems, it is less likely to be a generic solu- 
tion to the problem, as it generally will bring us right back to the combinatorial 
explosion that we want to avoid. 

In practice verification models are not formally derived or proved, but con- 
structed on the basis of a combination of insight, heuristics, and sometimes 
formally well-defined abstractions. This principal loss of a formal link between 
the formal definition of a system and its effective verification model may be 
lamented, but it has a positive side to it. The availability of complete formal 
specifications of systems that we want to verify may help, but is no longer an ab- 
solute requirement. This is important as for complex systems such specifications 
are as a rule not available, and the cost of producing them is often prohibitively 
expensive. Smaller, more abstract specifications that suffice for the verification 
of some crucial correctness properties, however, could help to increase confidence 
in the correctness of a system in a more realistic price-performance ratio. 

Also, it should be realised that the relation between formal specifications of 
complex systems and their realisations is more problematic than that between 
programs and their inplementations. Complex systems generally cannot be pro- 
duced by just using reliable compiler(s), and often need elaborate engineering 
involving both hardware and software, requiring solutions that are unique to the 
given system. This implies that if we want to assess not only the correctness of 
a formal design, but actually want to analyse properties of the resulting system, 
its formal specification may not be the only relevant source of information. 

We thus find ourselves in a situation in which the validity of many of our 
verification models cannot be demonstrated by formal means. This means that if 
we want to assess their validity, and we must if we take our job seriously, we can 
only use experimental methods. Moreover, this experimental validation is not 
just a phase born out of temporary necessity, but that it constitutes an essential 
methodological ingredient for the verification of real-life systems. As in physics, 
it is the tool to bridge the orders of magnitude that lie between a complete 
description of a system and an effective theory of its properties (cf. an extremely 
large set of molecules vs a volume of gas). It is worthwhile mentioning that in 
physics one can also quantify the consequences of such abstractions and show 
that the errors incurred are sufficiently small. In this respect it is interesting to 
note that in performance analysis often great simplifications of the evaluation 
models can be obtained without significant loss of precision. Such approximative 
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abstractions are not feasible if evaluation is restricted to evaluation in the binary 
system of classical logic. Stochastic interpretations of behaviour can perhaps 
provide a way forward in this respect: they would allow abstracting away from 
behaviours that are sufficiently unlikely. 

Because the experimental paradigm is foreign to many who are active in the 
field of formal methods, its role is seldom explicitly addressed and if acknowl- 
edged, it is usually delegated to the engineers of “real” systems and the testing 
community. But the engineering of verification models is a task that requires 
intimate knowledge of the formal methods that are used, and therefore should 
concern all who are interested in the application of verification. 

What is needed is agreement on what constitutes good verification practice. 
If we take our inspiration from the established experimental sciences, we should 
follow a protocol that includes the following ingredients: 

— Problem statement: clearly defines the problem that is adressed. It answers 
questions like: 

• What is the system or design that must be verified? 

• What are the properties that must be verified? 

• What assumptions are made? 

~ Verification set-up: describes the ingredients of the verification, their use and 
relation accurately, so that all will be repeatable by others. Related questions 
are: 

• What verification model is used? 

• How are the properties formalised? 

• What tools and computing equipment are used? 

(versions, relevant system parameters) 

• What procedure was followed? 

— Measurements: gives all the relevant data that were obtained. 

— Error discussion: evaluates systematically all sources of errors that could 
have influenced the measurements. In particular, this section should address 
the quality of the verification model that was used. 

— Conclusion: presents the final outcome of the verification. Generally, this is 
not a simple yes/no-answer, but an qualitative and/or quantitative interpre- 
tation of the measurements in the context of the error discussion. 

Current verification practice is often opaque, not because it does not include 
activities to validate the verification model, but because it does not make them 
explicit and does not relate them via an error discussion to the results. What 
complicates matters is that the debugging of a verification model is often inter- 
leaved with the verification itself, when during verification unexpected properties 
are encountered that are not related to errors in the original system, but to er- 
rors in the model. This can lead to a continuous improvement of the verification 
model itself, and requires precise bookkeeping of model versions and properties 
verified. The quality of this process has decisive influence on the quality of the 
verification procedure as a whole. 

So far, we have looked at experimentation as a way to improve the practical 
applicability of formal verification. In the next section we want to present yet 



Verification Is Experimentation! 



23 



another angle that links verification to empirical methods, viz. in the scientific 
evaluation of formal methods. 

4 Verification and the Methodology of Computer Science 

From time to time the question concerning the nature of computer science 
among the sciences is raised. Hartmanis addressed this question in his 1993 
Turing Award Lecture, which led to a subsequent discussion published in the 
ACM Computing Surveys [3,1]. Hartmanis’ own conclusion is not very precise: 
he qualified computer science as a new species among the known sciences for 
which “a haunting question remains about analogies with the development of 
physics” . Even so, he reports on the coexistence of science and engineering as- 
pects, and remarks: “Somewhat facetiously, but with a grain of truth in it, we 
can say that computer science is the engineering of mathematics (or mathemat- 
ical processes)”. The authors in [1] take various positions, some defending the 
experimental science point of view, others emphasising the engineering aspects, 
and yet others argue for both. The overall impression is that at that time there 
was no general agreement. 

Interestingly enough, already in 1986 Robin Milner gave an account of the 
experimental nature of a good part of computer science in [5]. He distinguishes 
between the hard core of computing theory, consisting of recursion and com- 
plexity theory, dealing with the characterisation and classification of what is 
computable, and mathematical theories “in the service of design”, i.e. theories 
that help making and analysing computational artifacts. He proposes that such 
theories must be evaluated experimentally, by using them in prototype method- 
ologies that are tried out in practice.^ This position is nicely reminiscent of the 
point of view taken by Herbert Simon in his Sciences of the Artificial [6]. He 
argues that in general the engineering of artifacts is based on an empirical sci- 
ence of implementation and realisation methods. Experimental design is used 
to determine the scope of effectiveness of the different methods: under which 
conditions and circumstances can they be applied successfully, and how to they 
influence the quality of the resulting product? 

In this context (computer aided) verification can be seen as experiments in 
the sense of Milner and Simon to determine the effectiveness of formal methods. 
Of course, there are many other experiments that one can think of, dealing with 
qualities other than correctness. But verification is a useful class of experiments 
because it can be tool supported and seems to lend itself better for purposes of 
comparison than, for example, entire system designs. 

The role of verification as experimention with formal methods suggests that 
we should also develop richer evaluation criteria for such experiments than seem 
to be in current use. Computer aided verification is strongly focussed on the 
performance (time, memory usage) of the software tools that are used. This is 
understandable from the existing drive towards faster and better verification 

^ A similar point of view was elaborated by the author in [2] 
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tools. Nevertheless, it is very important to know to what extent other aspects of 
verification are (not) supported in different formal frameworks, such as the rela- 
tive ease of validating a verification model, of obtaining a verification model, of 
selecting and formalising correctness criteria, etc. These observations imply that 
it is important to repeat and compare verifications using different formalisms 
and tools. The results of such repeated experiments should be publishable. This 
should also hold for failed attempts, provided that interesting lessons can be 
distilled from such failures. 

Publications like [4] suggest that computer science compares badly with other 
branches of science, in the sense that relatively few papers are published with 
experimentally validated results. Every real opportunity to validate our methods 
should therefore exploited, and we should strive for a culture that is comparable 
to that in the other sciences, viz. that in the long run there is no place for formal 
methods that have not been validated by serious experimentation. 
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In this talk, I give an overview of some recent work, by my colleagues and me at 
Stony Brook, concerning compositional specification and performance analysis 
techniques for finite-state reactive systems in which probability and timing play 
a significant role. 

By reactive systems, I mean concurrent systems whose components main- 
tain an ongoing interaction with their environments. The complexity of such 
systems typically resides not in the calculations to be performed by individ- 
ual system components, but rather in timing and other details of the interac- 
tions between components. Examples of reactive systems incude process control 
software, telecommunication security and e-commerce protocols, and embedded 
systems. By compositional specifications I mean those in which complex systems 
are described in a hierarchical and modular way as compositions of simpler com- 
ponents. By compositional performance analysis I mean performance analysis 
techniques that exploit the modular structure of a system description and work 
in a component-by-component fashion to calculate performance measures. 

In our work [WSS97,SS98,SP99], we have introduced Probabilistic I/O Au- 
tomata (PIOA) as a model for reactive systems in which probability and timing 
are of importance. The PIOA model is a probabilistic adaptation of the I/O 
automata model developed by Nancy Lynch and her students [Lyn96]. A key 
feature of the I/O automata model is the operation of composition, by which a 
“compatible” collection of I/O automata can be combined into a single, larger 
automaton. The notion of composition depends in an essential way on a distinc- 
tion made in the I/O automata model between input actions, which are stimuli 
applied to an automaton by its environment, output actions, which are responses 
made by an automaton to its environment, and internal actions, which represent 
internal steps in which the automaton does not interact with its environment. 
Output and internal actions are called locally controlled, because their occur- 
rence is under the control of the automaton, whereas input actions are under 
the control of the environment, with the automaton unable to exert any influence 
over their occurrence. 

The PIOA model integrates probability and timing into the I/O automata 
model, while carrying over in a natural way its essential features of asyn- 
chrony and compositionality. To the original I/O automata model, two kinds 
of probability-related information are added. First, probability distributions are 

* Research supported in part by AFOSR Grant F49620-96-1-0087. 
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associated with each state q of an automaton, in such a way that for each input 
action a, there is one probability distribution covering all transitions for action a 
from state g, and such that there is one additional probability distribution cover- 
ing all transitions for locally controlled actions from state q. The second type of 
probabilistic information included in the PIOA model consists of a rate associ- 
ated with each state. The rate is a nonnegative real number, which we interpret 
as the parameter of an exponentially distributed random variable that describes 
the amount of time spent by an automaton in a state before it executes its next 
locally controlled action. Rates enable us to “probabilize” the scheduling of lo- 
cally controlled transitions taken by a system of component PIOAs, according 
to the following race criterion: upon entering a state, each component PIOA 
chooses randomly, according to the exponential distribution whose parameter is 
the rate of that state, a nonnegative real number that represents the amount of 
time that PIOA will remain in this state before executing the next locally con- 
trolled action. The times chosen by each of the component PIOAs are compared, 
the PIOA that has chosen the smallest time is declared “the winner,” and it is 
allowed to perform the next locally controlled action at the time it has chosen. 

A PIOA with an empty set of input actions is called closed. Closed PIOAs 
determine continuous-time Markov chains (CTMCs) [How7I], which are widely 
used in modeling and performance analysis. An important reason for the 
widespread use of CTMCs is that they can, in fact, be analyzed — algorithms 
exist to “solve” the CTMC to compute performance measures that predict the 
behavior of the real system. For example, the steady-state probabilities for a 
CTMC describe the fraction of time spent by the system in each state over the 
long run, and these probabilities can be obtained by solving a system of linear 
“balance equations” associated with the CTMC. From the steady-state prob- 
abilities, one can compute the mean recurrence times, which describe, on the 
average, how long it will take for a system to return to a state it has just left. 
The reciprocals of the mean recurrence times can be interpreted as throughputs, 
which are often useful performance parameters that can actually be measured 
for a real system. 

The PIOA model is closely related to stochastic process algebras such as 
EMPA [BDG98], PEPA [Hil96], and TIPP [HR94], whose stochastic semantics 
are also described in terms of an underlying CTMC. Significant differences be- 
tween the PIOA model and these other stochastic process algebras are: (1) the 
PIOA model does not attempt to treat any form of non-probabilistic internal 
choice, and (2) in the PIOA model, a syntactic distinction is drawn between 
output (“active”) actions and input (“passive”) actions, and at most one com- 
ponent can be active in any synchronized action. These restrictions enable the 
PIOA model to avoid semantic problems associated with assigning probabilities 
to synchronized actions. 

Traditional techniques [Ste94] for performance analysis of a CTMC system 
model typically proceed by first compiling the system description into a matrix 
representation of a CTMC. An iterative numerical method, such as Gauss-Seidel 
iteration or successive overrelaxation, is then used to solve the system to obtain. 
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for example, the steady-state probabilities. Although the matrices arising in 
practice from CTMC descriptions are generally sparse, and require storage space 
which is linear in the number of states of the CTMC, if no steps are taken to 
reduce the size of the CTMC representation, the amount of memory needed to 
store it limits the maximum size of models that can be solved. Typical maximum 
sizes of CTMCs that can be treated by standard methods are somewhat in excess 
of 10® states. This sounds like a lot of states, until one realizes that it only takes 
six components, with each component having ten states, to describe a system 
with this many global states. This severely limits the applicability of standard 
techniques to even relatively simple real-world systems. 

The PIOA-based techniques we have developed can be used to give a de- 
scription of a CTMC as the composition of a collection of PIOA components, 
and then to exploit the compositional structure of the system description in the 
calculation of performance measures, thereby avoiding the construction of the 
full CTMC state space. Our techniques are applied by starting with a represen- 
tation of a particular performance measure to be calculated, and then treating 
the system one component at a time. As each component is treated, state-space 
reduction is performed before proceeding to the next component. This reduction 
step eliminates information that is not relevant to the computation of the per- 
formance measure of interest. The overall idea is similar to the compositional 
aggregation technique of Hillston [Hil95], except that we use a very different 
state-space reduction algorithm and we are able to use information about the 
performance measure to enhance the reduction. 

Our techniques most naturally apply to the calculation of transient per- 
formance measures that can be expressed as expectations of a certain kind of 
function over the probability space of system executions. Some examples of per- 
formance measures that can be expressed in this way are: (1) the probability of 
a total failure of all components, in a system in which components fail and are 
repaired after some time; (2) the expected time until a total failure in such a sys- 
tem, assuming that such a failure will occur with probability one. We have also 
shown that our techniques can be applied to compute steady-state performance 
measures, by viewing them as limits of transient measures. 

Our methods for compositional analysis of systems of PIOAs are based on a 
kind of abstract semantics for PIOAs that retains just the information required 
for performance analysis. The main notions in the theory are: rated traces, which 
are alternating sequences of rates and actions that form a kind of abstraction of 
PIOA executions; observables, which are measurable functions from rated traces 
to real numbers, and whose expectations correspond to performance measures; 
and PIOA behaviors, which are functions from observables to observables that 
capture the way in which system performance is modified by the incorpora- 
tion of an additional PIOA as a system component. A compositionality theorem 
states that PIOA behaviors compose: the behavior of a composite system can 
be obtained by composing (as functions) the behaviors of the individual system 
components. 
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Our algorithms for compositional performance analysis work for representable 
observables, which are those that have a linear representation as a certain kind 
of automaton with states in a finite-dimensional vector space. Linear represen- 
tations of observables are a generalization of the classical notion of linear repre- 
sentations for formal power series [BR84] . We have shown [SS98] that algorithms 
exist for: (1) calculating the result of applying the behavior of a finite-state PIOA 
to a representable observable; (2) finding, given a linear representation of an ob- 
servable, a minimum-dimension linear representation for that same observable; 
and (3) calculating the expectation of an observable to obtain a performance 
measure. We have implemented our algorithms in the very high-level functional 
programming language Standard ML. A description of the implementation and 
the results of applying it to some examples can be found in [SP99]. 
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Abstract. Concurrency is an essential element of abstract models for 
embedded systems. Correctness and efficiency of the design depend crit- 
ically on the way concurrency is formalized and implemented. Concur- 
rency is about communicating processes. We introduce an abstract for- 
mal way of representing communication among processes and we show 
how to refine this representation towards implementation. To this end, 
we present a formal model. Abstract Co-design Einite State Machines 
(ACFSM), and its refinement, Extended Co-design Finite State Ma- 
chines (ECFSM), developed to capture abstract behavior of concurrent 
processes and derived from a model (Co-design Finite State Machine 
(CFSM)) we have used in POLIS, a system for the design and verifi- 
cation of embedded systems. The design of communication protocols is 
presented as an example of the use of these formal models. 



1 Introduction 

By the year 2002, it is estimated that more information appliances will be sold 
to consumers than PCs (see Business Week, March 1999). This new market 
includes small, mobile, and ergonomic devices that provide information, enter- 
tainment, and communications capabilities to consumer electronics, industrial 
automation, retail automation, and medical markets. These devices require com- 
plex electronic design and system integration, delivered in the short time frames 
of consumer electronics. The system design challenge of at least the next decade 
is the dramatic expansion of this spectrum of diversity and the shorter and 
shorter time-to-market window. Given the complexity and the constraints im- 
posed upon design time and cost, the challenge faced by the electronics industry 
is insurmountable unless a new design paradigm is developed and deployed that 
focuses on: 

— design re-use at all levels of abstraction; 

— “correct-by-construction” transformations. 

An essential component of a new system design paradigm is the orthogo- 
nalization of concerns, i.e., the separation of the various aspects of design to 
allow more effective exploration of alternative solutions. The pillars of the de- 
sign methodology that we have proposed over the years are: 
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— the separation between function (what the system is supposed to do) and 
architecture (how it does it); 

— the separation between computation and communication. 



1.1 Fund ion- Architecture Co-design 

The mapping of function to architecture is an essential step from conception 
to implementation. In the recent past, there has been a significant attention in 
the research and industrial community to the topic of Hardware-Software Co- 
design. The problem to be solved here is coordinating the design of the parts 
of the system to be implemented as software and the parts to be implemented 
as hardware, avoiding the HW/SW integration problem that has marred the 
electronics system industry for so long. We actually believe that worrying about 
hardware-software boundaries without considering higher levels of abstraction 
is the wrong approach. HW/SW design and verification happens after some es- 
sential decisions have been already made, thus making the verification and the 
synthesis problem so hard. SW is really the form that a given piece of func- 
tionality takes if it is “mapped” onto a programmable microprocessor or DSP. 
The origin of HW and SW is in behavior that the system must implement. The 
choice of an “architecture”, i.e. of a collection of components that can be either 
software programmable, re-configurable or customized, is the other important 
step in design. 




Functional Level 



Mapping Levei 



Architecturai Level 



Fig. 1. Proposed design strategy 



1.2 Communication-Based Design 

The implementation of efficient, reliable, and robust approaches to the design, 
implementation, and programming of concurrent systems is essential. In any 
large-scale embedded systems design methodology, concurrency must be consid- 
ered as a first class citizen at all levels of abstraction and in both hardware and 
software. 

Concurrency implies communication among components of the design. Com- 
munication is too often intertwined with the behavior of the components of the 
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design so that it is very difficult to separate out the two domains. Separating 
communication and behavior is essential to dominate system design complexity. 
In particular, if in a design component behaviors and communications are inter- 
twined, it is very difficult to re-use components since their behavior is tightly 
dependent on the communication mechanisms with other components of the 
original design. In addition, communication can be described at various levels 
of abstraction, thus exposing the potential of implementing communication be- 
havior in many different forms according to the available resources. Today this 
freedom is often not exploited. 



1.3 Formal Models 

We have promoted the use of formal models and transformations in system 
design so that verification and synthesis can be applied to advantage in the 
design methodology [1]. Further, the concept itself of synthesis can be applied 
only if the precise mathematical meaning of a description of the design is applied. 
It is then important to start the design process from a high-level abstraction that 
can be implemented in a wide variety of ways. The implementation process is a 
sequence of steps that remove freedom and choice from the formal model. In other 
words, the abstract representation of the design should “contain” all the correct 
implementations in the sense that the behavior of the implementation should 
be consistent with the abstract model behavior. Whenever a behavior is not 
specified in the abstract model, the implicit assumption is that such behavior is a 
“don’t-care” in the implementation space. In other words, the abstract model is a 
source of non-deterministic behavior, and the implementation process progresses 
towards a deterministic system. It is important to underline that way too often 
system design starts with a system specification that is burdened by unnecessary 
references to implementations resulting in over-determined representations with 
respect to designer intent that obviously yield under-optimized designs. 

In the domain of formal model of system behavior, it is common to find the 
term “Model of Computation” (MOC), an informal concept that has its roots in 
language theory. This term refers more appropriately to mathematical models 
that specify the semantics of computation and of concurrency. In fact, concur- 
rency models are the most important differentiating factors among models of 
computation. Ed Lee [2] has very well stressed the importance of allowing one 
to express designs making use of all models of computation, or at least of the 
principal ones, thus yielding a so-called heterogeneous environment for system 
design. In his approach to simulation and verification, assembling a system de- 
scription out of modules represented in different models of computation reduces 
to the problem of arbitrating communication among the different models. How- 
ever, the concept of communication among different models of computation still 
needs to be carefully explored and understood from a synthesis and refinement 
viewpoint. 

This difficulty has actually motivated our approach to communication-based 
design where communication takes the driver seat in system design [7]. In this 
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approach, communication can be specified somewhat independently of the mod- 
ules that compose the design. In fact, two approaches can be applied here. In the 
first case, we are interested in communication mechanisms that “work” in any 
environment, i.e., independently of the formal models and specifications of the 
behavior of the components. This is a very appealing approach if we look at the 
ease of component assembly. It is however rather obvious that we may end up 
with an implementation that is overly wasteful, especially for embedded systems 
where production cost is very important. A more optimal (but less modular) 
approach is to specify the communication behavior, and then to refine jointly 
one side of the communication protocol and the behavior that uses it, in order 
to exploit knowledge of both to improve the efficiency of the implementation. 
Here, a synthesis approach is most appealing since it reduces the risk of making 
mistakes and it may use powerful optimization techniques to reduce design cost 
and time. 

Communication and time representation in a Model Of Computation are 
strictly intertwined. In fact, in a synchronous system, communication can take 
place only at precise “instants of time” thus reducing the risk of unpredictable 
behavior. Synchronous systems are notoriously more expensive to implement and 
often less performing thus opening the door to asynchronous implementations. 
In this latter case, that is often the choice for large system design, particular 
care has to be exercised to avoid undesired and unexpected behaviors. The bal- 
ance between synchronous and asynchronous implementations is possibly the 
most challenging aspect of system design. We argue that globally asynchronous 
locally synchronous (GALS) communication mechanisms are probably a good 
compromise in the implementation space [1]. The research of our group in the 
last few years has addressed the above problems and allowed us to define a full 
design methodology and a design framework, called Polls [1], for embedded sys- 
tems. The methodology that we have proposed is based on the use of a formal and 
implementation-independent MOC, called CFSMs (Co-design Finite State Ma- 
chines). CFSMs are Finite State Machines extended with arithmetic data paths, 
and communicating asynchronously over signals. Signals carry events, which are 
buffered at the receiving end, and are inherently uni-directional and potentially 
lossy (in case the receiver is not fast enough to keep up with the sender’s speed) . 
The CFSMs model is Globally Asynchronous Locally Synchronous (GALS), since 
every CFSM locally behaves synchronously following the FSMs semantics while 
the interaction among CFSMs is asynchronous from a system perspective. 

However, the view of communication in CFSMs is still at a level of abstrac- 
tion that is too low. We would like to be able to specify abstract communica- 
tion patterns with high-level constraints that are not implying yet a particu- 
lar model of communication. For example, it is our opinion that an essential 
aspect of communication is the guarantee of reception of all the information 
that has been sent. We argue that there must exist a level of abstraction that 
is high enough to require that communication takes place without loss. The 
synchronous- asynchronous mechanism, the protocols used and so on, are just 
implementation choices that either guarantee no loss or that have a good chance 
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of ensuring that no data is lost where it matters (but that need extensive ver- 
ification to make sure that this is indeed the case). For example, Kahn process 
networks [4] guarantee no loss at the highest level of abstraction by assuming an 
ideal buffering scheme that has unbounded buffer size. Clearly the unbounded 
buffer size is a “non-implementable” way of guaranteeing no loss. When moving 
towards implementable designs, this assumption has to be removed. A buffer can 
be provided to store temporarily data that are exchanged among processes but 
it must be of finite size. The choice of the size of the buffer is crucial. Unfortu- 
nately deciding whether a finite buffer implementation exists that guarantees no 
loss is not theoretically feasible in the general case, but there are cases for which 
an optimal buffer size can be found [2]. In other cases, one has to hope for the 
best for buffer overwrite not to occur or has to provide additional mechanisms 
that, when composed with the finite buffer implementation, still guarantee that 
no loss takes place (for example, a request/acknowledge protocol). Note that in 
this case the refinement process is quite complex and involves the use of com- 
posite processes. Today, there is little that is known about a general approach 
to communication design that has some of the feature that we have exposed. 

An essential step to develop communication-based design is the understanding 
of “communication” semantics. We believe that communication in formal models 
has not been treated at the correct level of abstraction. 

1.4 Outline of the Paper 

In Section 2, we present a model for communication semantics and use it to 
describe the FIFO communication mechanism. This mechanism is used in the 
two models introduced in Section 3 obtained by “abstracting” Co-design Finite 
State Machines (CFSMs) to deal with the problems posed by communication- 
based design. Finally, in Section 4 we show how to use these models to design 
an application example: a wireless communication protocol. 

2 Communication 

Large distributed systems are composed of a set of concurrent and interacting 
components 

A prerequisite for the interaction between distinct components is the ex- 
istence of a connection between an output port of one component, called the 
sender, and an input port of another component, called the receiver. A connec- 
tion can be modeled as a process whose function is the identity between input 
and output signals. With respect to the interaction between sender and receiver, 
a connection imposes the equality of the input signal of the receiver with the 
output signal of the sender (Figure 2). 

^ Following the Tagged Signal Model formalism [3], system components are modeled 
as functional processes, whose set of behaviors is defined by a mapping from a set 
of input signals I to a set of output signals O, F ■. I ^ O. Unless a definition is 
explicitly given, terms like process, signal, behavior are used in this paper as in [3]. 
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Fig. 2. Connection Process 



Consider two components, the sender modeled by process S (Fg : Ig ^ Og) 
and the receiver by process R {F^ : R => Or). Connecting S and R as shown 
in Figure 3 implies that only a signal that is an output of S may be an input 
of R. As a result, the input space of R is restricted to the intersection Og fl R 
of its domain R with the output space of S (Figure 3). When the domain of R 
includes a signal v ^ Og, the connection results in a restriction of the set of 
possible behaviors of R that can be optimized by removing the behaviors that 
correspond to the input signals ir & Og C\ Ir- 



2.1 Adapters 

If the set Og D R is not empty, we say that the behaviors of S and R are not 
adapted, since the behavior of R is not defined for inputs o* G Os fl This 
mismatch ^ can be solved in one of the following ways: 

1. R discards inputs o* and treats them as errors, 

2. outputs o* of S and the behaviors originating them are removed from S', 

3. signals o* are mapped into signals that can be accepted by R. 




Fc - id 




Fig. 3. Behavior mismatch 

^ An example is when the sender is an analog system and the receiver is digital: an 
A/D converter is needed to allow the receiver to understand the messages of the 
sender. 
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In 1) the set of behaviors of R is extended to R' to include the error handling 
of the undesired input signals that may be received. In 2) the behavior of the 
sender is optimized and restricted to S' to exclude the production of output 
signals incompatible with R. In 3) an interface (represented in Figure 4 as a 
process with function Fi,(,h_int) is used to map the signal emitted by S into a 
signal that belongs to the domain of R. Such an interface [8] can be usually 
split into two processes {Fbeh.int = Fbeh.smt ° Fbeh_rint)), which encapsulate S 
and R (Fg/ = FgO Fbeh.sint and Fj./ = Fbeh.rint o Fr) and permit communication 
between the modified behaviors S' and R' over a connection. We call this type 
of interface Behavior Adapter (BA) (Figure 4). 





Fig. 4. Behavior Adapter 



2.2 Channels 

Connections are implemented using physical channels (Figure 5) ^ , whose func- 
tion (Fc : Ic Oc) in general differs from the identity, e.g. due to noise or 
interference. As a result, even if the behaviors S' and R' were perfectly adapted, 
the received signal Fciic) = Fc{os) might be out of the domain of R' or trigger 
an incorrect behavior of R. Therefore, for a safe and correct interaction among 
system components it is key to select a channel whose behavior approximates 
that of the ideal connection. 

Quality of Service (QoS) requirements partition the set of behaviors F into 
two classes, the class of those that satisfy them and the class of those that do 
not satisfy them. Let us introduce a relation ~C F x F, such that 

~= {(/, f')\f e F, f € F, both f and f’ satisfy the quality requirements}. 

Two processes / and /' such that / ~ /' are said to be QoS-equivalent. 
Given a connection and a set of requirements on the quality of the received 
signal, the set of the behaviors Fg o Fc o Fr, where Fc is the channel function, 

® A connection establishes a relation between signals. A channel is a set of physical 
objects that implement a connection. 

Quality of Service requirements include maximum delay, minimum throughput, max- 
imum number of errors. 
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is partitioned into two classes: the class of valid channels and the class of the 
invalid ones. The former includes all the channels that guarantee satisfaction of 
the requirements on the quality of the received signal ® . Since the ideal connection 
(identity function id) by definition satisfies the quality requirements, the set of 
valid channels can be defined as: 

V alidChannels = {Fc : o Fc o Fr ^ Fg o Fr} 

The first step in designing a valid channel is to select a physical channel 
whose function is Fg. If the channel is invalid due to its physical limitations, it is 
necessary to introduce an interface between the behaviors and the channel that 
matches the undesired effects. We call this type of interface Channel Adapter 
( CA ) ^. A channel adapter interface is usually symmetric to the channel and is 
defined by two functions, (Fcs_int) implementing the sender-channel and {Fcr_int) 
the channel-receiver interfaces (Figure 5). If FgoFcs_intoFcoFcr_intoFr ~ FgoFr 
the interface successfully adapts the channel F^ otherwise it is necessary to iter- 
ate the adaptation process and look for two other functions Fcs'_int and Fcr'_int 
such that FsoFcs_xntoFcs'_intoFcoFcr'_int°Fcr_intoFr ~ FgoFr Note also that 
if channel adapters introduce some mismatch between the range of Fcs_int ° Fc 
and the domain of Fcs_int a behavior adapter is needed. 




Fig. 5. Channel Adapter 



® No losses is one of the possible QoS requirements for a communication. For such 
requirement valid channels are called lossless, invalid channels lossy. 

® Example of Channel Adapters functions are: error correction, flow control, medium 
access control. 

^ The channel adapter interface often consist of several layers, each adapting the chan- 
nel at a different level of abstraction. 
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2.3 Communication and Protocols 

We define communication as a composition of processes that is QoS equivalent to 
the identity process. A protocol is the sequence of behavior and channel adapters 
that implement a communication. 

Figure 6 describes the flow we propose for designing protocols. Given two 
components S and R, they are first connected and their behaviors are compared. 
If there is a need for a behavior adapter BA, this is introduced. The next step 
is the selection of channel CH. If there is no valid channel available, a channel 
adapter composed of the two interfaces CRA (channel-receiver adapter) and SCA 
(sender-channel adapter) is introduced to overcome the limitations of the invalid 
channel selected. If the behavior of the sender composed with the channel and 
the behavior of the receiver are not adapted, another behavior adapter is needed. 
This procedure is iterated until the behaviors no longer need to be adapted and 
a valid channel is defined. 




Fig. 6. Design Flow 
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2.4 Communication over FIFO Channels 

A FIFO channel can be seen as an adapter between behaviors that operate at a 
different rate. If the sender produces outputs at a faster rate than the receiver, 
a FIFO allows to handle their rate difference and prevent from losses. 

An unbounded queue is an ideal adapter, since it allows to accumulate an 
infinite number of tokens and therefore match any rate difference. However, 
communication has to be implemented using channels that have finite queues. 
Unfortunately, bounded FIFO channels do not prevent from overflow, i.e. losses, 
when the FIFO is full. For this reason, a bounded FIFO channel may not be 
a valid channel, especially for systems where the rate difference between sender 
and receiver is large. In this case, it is necessary to introduce a channel adapter 
interface that may take the form either of a scheduling policy or an explicit 
Request/ Acknowledgment protocol that blocks the sender when the FIFO is full. 
In particular the Req/ Ack protocol restricts the behavior of S to 5" excluding all 
the behaviors, considered illegal, where the number of consecutive output events 
exceeds the capacity of the queue (Figure 7). 




Fig. 7. Fifo Channel 



3 Abstract and Extended Codesign Finite State Machines 

A network of Co-design Finite State Machines was introduced in [1] to model 
formally the behavior of embedded systems. It consists of a network of FSMs 
that communicate asynchronously by means of events (that at the abstract level 
only denote partial ordering, not time) over signals with FIFO semantics. A 
network of CFSMs is a Globally Asynchronous Locally Synchronous (GALS) 
model: 

— the local behavior is synchronous {from its own perspective, like the “atomic 
firing” of Dataflow actors), because each CFSM executes a transition by 
producing an output reaction based on a snap-shot set of inputs in zero 
time, 

— the global behavior is asynchronous {as seen by the rest of the system) since 
each CFSM detects inputs, executes a transition, and emits outputs in an 
unbounded but finite amount of time. 
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The asynchronous communication among CFSMs over a FIFO channel, where 
the FIFO had a length of one, supports a (possibly very non-deterministic) 
specification where the execution delay of each CFSM is unknown a priori and, 
therefore, is not biased towards a specific hardware/software implementation. 

The FIFO channel of length one was appropriate for some control-dominated 
application but it lacked flexibility to model other applications especially in the 
communication and consumer electronics domains. In those cases, we noted that 
there was value in decoupling the behavior of each CFSM from the communi- 
cation with other CFSMs and in allowing an ideal communication mechanism 
where the FIFO channel is unbounded. This is the origin of the network of Ab- 
stract Co-design Finite State Machines (ACFSM) ACFSM. The communication 
can then be designed by refinement independently from the functional specifi- 
cation of the ACFSMs to yield a network of Extended Co-design Finite State 
Machines ECFSM with finite (and hence implementable) FIFO channels®. 



3.1 Single A(E)CFSM Behavior 

A single ACFSM (ECFSM)® describes a finite state control operating on a data 
flow. It is an extended FSM, where the extensions add support for data handling 
and asynchronous communication. An ACFSM transition can be executed when 
a pre-condition on the number of present input events and a boolean expression 
over the values of those input events is satisfied. During a transition execution, 
an ACFSM first atomically detects and consumes some of the input events, then 
performs a computation by emitting output events with the value determined 
by expressions over detected input events. A key feature of ACFSMs is that 
transitions in general consume multiple events from the same input signal, and 
produce multiple events to the same output signal {multi-rate transitions). We 
formally define an ACFSM as follows: 

Definition 1. An ACFSM is a triple A = {I, 0 ,T): 

~ I = . . . In} is a finite set of inputs. Let fl indicate the event that at 

a certain instant occupies the j-th position in the FIFO at input li. 

— O = {Oi, O2, . . . Om] is a finite set of outputs. Let 0} indicate the j-th event 
emitted by a transition on output Oi. 

^ T Q {{IR,IB,CR,OR,OB)} is the transition relation, where: 

• IR is the input enabling rate, 

IR = {{h,iri), {I2,ir2), ■ ■ ■ , {InAtn) \ 

1 < n < IV, /„ e J, ivn e IN} 

i.e., iVn is the number of input events from each input /„ that are required 
to trigger the transition. 

® Note that a network of CFSMs is a particular case of network of ECFSM. 

® From now on, in this subsection we refer to both ACFSM and ECFSM behavior. 
Hence ACFSM can be substituted with ECFSM to obtain the behavior of a single 
ECFSM. 
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• IB is a boolean-valued expression over the values of the events 
{i{}, 1 < i < N,1 < j < ir^ 

that enable the transition. 

• CR is the input eonsumption rate, 

CR = {(/i, cri), (/ 2 , cr 2 ), . . . , {In, crN) \ 
l<n<N,In€l, cr„ € N, 
cr„ < irn V cr„ = I^^^) 

i.e., cr„ is the number of input events consumed from each input^^ . 

• OR is the output production rate, 

OR = {{Oi,ori), ( 02 , 0 x 2 ), ..., (OM,orM) \ 

1 < m < M, Om G O, orm G N} 

i.e., OTn is the number of output events produced on each output On 
during a transition execution. 

• OB is a set of vectors of expressions that determines the values of the 
output events, one vector per output with ovn > 0 and one element per 
emitted event. 

{Oii) I<i<N,l<j<oTi 



Note that signals that are at the same time input and output, and for which 
a single event is produced and consumed at each transition act as implicit state 
variables of the ACFSM. 

If several transitions can be executed in a given configuration (events and 
values) of the input signals, the ACFSM is non-deterministic and can execute 
any one of the matching transitions. 

ACFSMs differ from Dataflow networks in that there is no blocking read 
requirement, i.e. ACFSMs transitions, unlike firings in DF networks, can be 
conditioned to the absence of an event over a signal. Hence, ACFSMs are also 
not continuous in Kahn’s sense [4] (the arrival of two events in different orders 
may change the behavior) . Another difference from DF models is that ACFSMs 
can “flush” an input signal, in order to model exception handling and reaction 
to disruptive events (e.g., errors and re-initializations). A DF actor cannot do 
so, since when the input signal has been emptied, the actor is blocked waiting 
on the signal, rather than proceeding to execute the recovery action. 

A difference from most FSM-based models (e.g., SDL) is the possibility to 
use multi-rate transitions to represent production and consumption of events 
over the same signal at different rates (e.g. images produced line-by-line and 
consumed pixel-by-pixel) . 

As an example, consider the filter shown in Figure 8. It filters a sequence of 
frames, by multiplying all the pixels of a frame by a coefficient. At the beginning 
of each iteration it receives the number of lines per frame and pixels per line 

The number of events that is consumed should be not greater than the number 
of events that enabled the transition. It is also possible to specify, by saying that 
CTn = In^^, that a transition resets a given input, i.e., it consumes all the events 
in the corresponding signal (that must be at least as many as those enabling the 
transition). 
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from the input signal in and the initial filtering coefficient (used to multiply the 
pixels) from the input signal coef . Then, it receives a frame, i.e. a sequence of 
lines of pixels, from in, possibly interleaved with new coefficient values (if it must 
be updated) from coef. The filtered frame is produced on the output signal out. 
The primitives read(in,n) and write(out,n) consume and produce n events from 
signal in and out, respectively, and present(coefn) returns true if n events are 
available on signal coef. 




module filter; 

input byte in, coef; 

output byte out ; 

int nlines, npix, line, pix; 

byte k; 

int buffer[]; 

forever { 

(nlines, npix) = read (in, 2); 
k = read (coef, 1); 

for (line = 1; line <= nlines; line++) { 
if (present (coef , 1)) k = read (coef, 1) ; 
buffer = read (in, npix) ; 
for (pix = 1; pix <= npix; pix++) 
buffer [pix] = buffer [pix] * k; 
write (out, buffer, npix); 

} 

} 



Fig. 8. Filter example 



Let prod(v,s,n) denote the multiplication of a vector v of n values by a 
scalar s, and “4=” a shorthand to represent writing to state feedback signals, 
which are also omitted for simplicity from IR and OR, where they always have 
rate 1. The filter can be modeled by an ACFSM as follows: 

— IR = CR = {(in, 2), (coef, 1)}, IB = (state = 1), 

OR = {}, OB = {(nlines, npix) 4= read(in, 2), 

line 4= 1, A: 4= read(coef, 1), state 4= 1} 

— IR = CR = {(in, npix)}, 

IB = (state = 2 A line < nlines), 

OR = {(out, npix)}. 



42 



Alberto Sangiovanni-Vincentelli et al. 



OB = {write(out, prod(read(in, npix), fc, npix), npix), 
state 4= 2, line 4= line + 1} 

— IR = CR = {(in, npix)}, 

IB = (state = 2 A line = nlines), OR = {(out, npix)}, 

OB = {write(out, prod(read(in, npix), fc, npix), npix), 
state <;= 1} 

— IR = CR = {(coef, 1)}, IB = (state = 2), 

OR = {}, OB = {fc read(coef, 1), state 4= 2} 

3.2 Network of ACFSMs and ECFSMs 

An ACFSMs (ECFSM) network is a set of ACFSMs (ECFSMs) and signals. The 
behavior of the network depends on both the individual behavior of each ACFSM 
(ECFSM), and that of the global system. In the mathematical model, the system 
is composed of ACFSMs (ECFSMs) and a scheduling mechanism coordinating 
them. The scheduler operates by continually deciding which ACFSMs (ECFSMs) 
can be run, and calling them to be executed. Each ACFSM (ECFSM) is either 
idle (waiting for input events), or ready (waiting to be run by the scheduler), or 
executing a single transition from its transition relation. 

The topology of the network, as for dataflow networks, simply specifies a par- 
tial order on the execution of the ACFSMs (ECFSMs). Initially the time required 
by an ACFSM (ECFSM) to perform a state transition is not specified, hence each 
ACFSM (ECFSM) captures all its possible hardware (with or without resource 
sharing constraints) and software (generally with CPU sharing constraints) im- 
plementations. The ACFSM model is fully implementation-independent but, as 
a consequence, it is highly non-deterministic. 

3.3 Refining ACFSMs 

The non-determinism present in ACFSMs is resolved only after an architectural 
mapping (implementation) is chosen. An architectural mapping in this context 
means: 

— a set of architectural and communication resources (CPUs, ASICs, busses, 

...), 

— a mapping from ACFSMs to architectural resources and from signals to 

communication resources, 

— a scheduling policy for shared resources. 

Once an architectural mapping is selected for a network of ACFSMs, the 
computation delay for each ACFSM transition can be estimated with a vari- 
ety of methods, depending on how the trade-off between speed and accuracy is 
solved [1]. 

Annotating the ACFSM transitions with such delay estimates defines a global 
order of execution of the ACFSM network that has now been “refined” into a 
Discrete Event semantics. At this level the designer can verify, by using a Discrete 
Event simulator [1], if the mapped ACFSM network satisfies not only functional 
but also performance and cost requirements. 
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Communication Refinement Abstract CFSMs communicate asynchronously 
by means of events, transmitting and receiving data over unbounded commu- 
nication channels with FIFO semantics. This abstract specification defines for 
each channel only a partial order between the emission and the reception of 
events and therefore must be refined to be implemented with a finite amount of 
resources. To implement an abstract communication it is necessary to design a 
protocol that satisfies the functional and performance requirements of the com- 
munication, and can be implemented at a minimum cost in terms of power, area, 
delay and throughput. 

The amount of data that should be correctly received is one requirement. A 
communication mechanism is called lossless, if no data (in the form of events) 
is lost over the communication channel during any system execution, and lossy 
otherwise. The specification requirements dictate if the communication must be 
lossless or lossy and, if lossy, how much loss is acceptable. Data can be lost 
either because of the poor quality of the physical channel, e.g. due to noise or 
interference, or because of the limited amount of resources in the implementation, 
e.g. the receiver is slow and does not have enough memory to store the incoming 
data. In the first case the problem is usually overcome by the definition of a 
robust protocol that (probabilistically) guarantees correctness of received data 
by means of re-transmissions or coding techniques for error correction. In the 
second case the solution, as discussed below, is to use a sufficient amount of 
resources or an appropriate protocol to meet the requirements. The throughput 
and the latency in the arrival of the data to the destination are key requirements 
especially in the design of protocols for real-time applications, e.g. real-time video 
or audio, that require that incoming video frames and audio samples are received 
and processed at regular intervals. 

Communication protocols in our approach are refined towards implementa- 
tion through several levels of abstraction, by applying a sequence of refinement 
steps, such that each step preserves the original behavior and constraints are 
propagated in a top-down fashion. At the same time the use of architectural 
units, e.g. the physical channel, and functional libraries, e.g. communication 
primitives, captures also the bottom-up aspect of the design process. Therefore, 
we can say that the overall methodology we propose is really a mix of top-down 
and bottom-up. 

Extended Co-design Finite State Machines At the Abstract CFSMs level, 
the specification includes the topology of the network and the functional be- 
havior of each module, while the protocols that implement the communication 
requirements are still undefined. To optimally design a protocol for each commu- 
nication channel it is necessary to use a model, or set of models, that allow to cap- 
ture different algorithmic solutions and evaluate their implementation costs. For 
this reason we introduce the Extended Co-design Finite State Machines (ECF- 
SMs) model that “implements” the ACFSMs model. ECFSMs are obtained from 
the ACFSMs simply by refining infinite-size queues to implementable finite-size 
queues. The event-based communication semantics, as well as the rules for the 
execution of ECFSMs transitions, are the same as in the ACFSMs model. 
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ECFSMs have input queues of finite size, and write operations can be either 
blocking or non-blocking (on a channel-by-channel basis). In the latter case, 
every time a queue is full and new data arrives over the channel, the data previ- 
ously stored is lost (overwritten). To avoid this scenario it is often sufficient to 
use a longer queue. Sometimes, instead, e.g. when the average production rate 
of the sender is greater than the average consumption rate of the receiver, there 
exists no finite-queue solution guaranteeing no loss. The problem of checking 
if there exists a lossless implementation with bounded queues, that has been 
solved using static or quasi-static scheduling algorithms for Synchronous Data 
Flow networks [5] and Free-Choice Petri Nets [6], is undecidable in general for 
the ACFSMs model. Therefore, to implement lossless communication in a given 
FCFSM network, it is necessary to define an additional mechanism that, when 
a queue is full, blocks the sender until the queue has again enough space for new 
incoming data. This can be achieved by means of either a handshake protocol, 
consisting of explicit events carrying the sender request for an emission and the 
receiver acknowledgment that new data can be accommodated in the queue, 
or scheduling constraints that ensure that the sender is scheduled for execution 
only when the queue at the receiver has enough space. Depending on the require- 
ments on data losses, ACFSM queues are refined into either lossy ones, that are 
eventually overwritten when they are full, or lossless ones, where overwriting is 
prevented by a blocking write protocol or scheduling constraints. 

The actual size of the queues should be determined by evaluating the cost 
of different implementations that satisfy the communication requirements. For 
example, large-size queues mean high throughput due to the higher level of 
pipelining that can be achieved by sender and receiver, but are also expensive in 
terms of area. Small-size queues reduce the area, but decrease the throughput, 
as the sender is blocked more often, and increase power consumption (more 
frequent request and acknowledgment messages). 



4 Example: A Wireless Protocol 

Intercom [9] is a single-cell wireless network supporting voice communication 
among a number of mobile terminals. The network operation is coordinated by 
a unit, called base station, that handles user service requests (e.g. request to 
establish a connection), and solves the shared wireless medium access problem 
using a TDMA (Time Division Multiple Access) policy and assigning the slots 
to communicating users. 

Figure 9 describes the Intercom protocol stack, that is composed of the fol- 
lowing layers. The User Interface Layer interacts with the users and forwards to 
lower layers user service requests and (logarithmically quantized) voice samples. 
The Transport Layer takes care of message retransmission until acknowledgment 
reception. The MAC Layer implements the TDMA scheme, keeping within in- 
ternal tables the information on which action (transmit, receive or standby) the 
terminal should take at each slot. The Error Control Layer applies the Cyclic Re- 
dundancy Check algorithm to the incoming and outgoing streams of data and. 
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Service ReqiKsts V dice samples 




Xx_data lif/Rx Rx_data 

Fig. 9. Intercom protocol stack 



if detects an error, discards the incorrect packet. The Synchronization Layer 
extracts from the received bit stream the frame aird slot synchroirization pat- 
terns, and irotifies the MAC of the begimring of a new slot. The Physical Layer 
iircludes computation-iirteirsive bit-level data processing functions, e.g. modu- 
lation, timiirg recovery. The Intercom protocol specification iircludes both data 
processing and control functions. It includes computation intensive functions 
(e.g. error control, logarithmic quantization) that are applied to the flows of (a) 
data samples and (b) service request /acknowledgment messages both in trans- 
mission and reception . Control functions include time-dependent and data- 
dependent control. The first type occurs at the MAC layer, where the processing 
and the transmission (or reception) of data flows is enabled using a time-based 
(TDMA) mechanism. Error control is instead a data-dependent control function 
since it enables some actions (e.g. discarding a packet) depending on the result 
of data computation. 

This mix of control-intensive and data-intensive aspects, often in the same 
functional layer, means that no design approach that separates between the 
two will provide (1) clear and concise specification of the functionality and (2) 
synthesis and optimizatioir capabilities. 

To model the Intercom protocol spedficatioir we have initially used ACFSMs. 
Their, starting from the communication requirements and taking into account the 
assumptions on the behavior of the environment, e.g. on the rates and patterns 
of the input events, we have refined the ACFSMs into implementable ECFSMs 

Service request and acknowledgment messages are part of the control fnnction at 
the network level, as they contribnte to the network coordination. However, at the 
node level, request messages are still data units processed and transmitted over the 
wireless channel. 
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and selected a communication protocol for each channel (currently this step is 
manual, but we are exploring ways of automating it). Since high-quality voice 
communication requires that no data is lost within the protocol stack due to 
buffer overflow, we have refined ACFSMs into lossless ECFSMs. Additional tim- 
ing requirement are imposed by the TDMA policy: data transmission can occur 
only within TDMA slots. Environmental assumptions concern the occurrence of 
the following input signals: Voice samples is periodic at 64 kbps, Rx-data is a 
periodic bit stream at 1.6 Mbps. Let us consider in detail the behavior of a pro- 
tocol stack fragment. Incoming voice samples are first processed by the Mulaw 
and sent to the CRC module that at each transmission slot is enabled by the 
MAC. The CRC input FIFO shapes the data stream to make it fit the TDMA 
slot allocation pattern and, since the read and write operations from this queue 
occur at regular times, in this case, the FIFO size can be simply computed from 
input/output rates and slotsize, and chosen to be 500 bytes. A smaller size would 
require to block the Mulaw module and introduce another queue at the input 
of Mulaw. A greater size does not give any advantage since 500 bytes is the 
maximum amount of data arriving during a frame. 

If we used the classical CFSMs model instead of ACFSMs, we would be 
forced to represent each FIFO as a CFSM. A CFSM of type FIFO calls, upon 
occurrence of external events, internal read and write functions that access an 
“internal” memory in FIFO manner. This implies that the CFSM at the receiver 
end of the channel (in this case CRC) has to explicitly make a request (in the 
form of an event) for new data as soon as it can process it. This results in an 
unnecessary overhead that is not present in the ACFSM model where FIFOs 
are part of the model and can be directly accessed by simple communication 
primitives. 

Finally, we also compared the design of the Intercom using our ACFSM-based 
methodology with a previous design [9] of the same specification done following 
an SDL-based approach. The overall design process turned out to be easier 
and more effective using ACFSMs due to their capability of modeling control 
and dataflow components independently from the final implementation. The 
previous approach, instead, due to SDL’s purely asynchronous nature, required 
to partition into hardware and software components from the beginning and 
model the hardware components directly in VHDL. This greatly reduced the 
design space and prevented from some system optimizations. 

5 Conclusions 

In this paper, we presented a new way of formalizing communication among 
processes, and refining and implementing it using physical channels and pro- 
tocol stack layers. We then introduced a new Model Of Computation called 
Abstract Codesign Finite State Machines, in which a finite state control coordi- 
nates multi-rate transitions and data-intensive computations. We described how 
a specification using ACFSMs can be refined, by queue sizing and static schedul- 
ing, until communication becomes implementable. We used a real-life example. 
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a wireless communication protocol, to illustrate how the abstract communica- 
tion can be refined to a concrete, implementable one, and we discussed the main 
trade-off's involved. 
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Abstract. In the design of programming languages for highly distrib- 
uted systems where processes can migrate and execute on new hosts, the 
integration of security mechanisms is a major challenge. In this paper, 
we report our experience in the design of an experimental programming 
language, called Klaim, which provides mechanisms to customize access 
control policies. Klaim security architecture exploits a capability-based 
type system to provide mechanisms for specifying and enforcing policies 
that control uses of resources and authorize migration and execution of 
processes. By means of a few programming examples, we illustrate the 
flexibility of the Klaim approach to support the specihcation of control 
policies and to guarantee their enforcement. 



1 Introduction 

Highly distributed systems and networks have now become a common platform 
for large scale distributed programming. Network applications distinguish them- 
selves from traditional applications for scalability (huge number of users and 
nodes), connectivity (both availability and bandwidth), heterogeneity (operating 
systems and application software) and autonomy (of administration domains 
having strong control of their resources). These features call for programming 
languages that support mobility of code and of computations, and for effective in- 
frastructures that support coordination of dynamically loaded (often untrusted) 
software modules. Current software computing environments exploit so called 
security architectures to monitor the execution of mobile code and protect hosts 
from external attacks. We refer the readers to [18] for a collection of papers 
dedicated to tackling these issues. 

Recently, the possibility has been explored of considering security issues at 
the level of language design, aiming at embedding dynamic linking of code and 
protection mechanisms in programming languages. The challenge is that of de- 
signing the language together with its secure kernel and to implement the corre- 
sponding secure abstract machine. In other words, security issues are taken into 
account when designing the programming language and not later for addition 
to existing infrastructures. This provides the users with suitable programming 
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mechanisms for defining their own security policies. A partial example of this 
approach is given by the Java 1.2 Security architecture [24]. 

In this paper we report our experience in the design of a language which sup- 
ports programming of security policies. We describe the security mechanisms of 
Klaim (a Kernel Language for Agents Interaction and Mobility) [13], an exper- 
imental programming language specifically designed for programming network 
applications. Klaim provides direct support for expressing and enforcing access 
control policies to resources and for authorizing migration and execution of mo- 
bile processes. Klaim exploits a capability-based type system to specify and 
enforce access control policies. 

Klaim consists of core Linda [11,10,5] with multiple located tuple spaces. A 
Klaim program, called a net, is structured as a collection of nodes. Each node 
has a name, and consists of a process component and a tuple space component. 
Sites are the concrete names of the nodes and are the main linguistic constructs to 
provide network references to nodes. Processes may access tuple spaces through 
explicit naming: operations over tuple spaces are indexed with their locality. 
Localities are the symbolic names of nodes and programmers need not to know 
the concrete network references, i.e. the precise association of localities with 
sites. The net primitives are designed to handle all issues related to physical 
distribution, scoping and mobility of processes: the visibility of localities, the 
allocation policies of tuple spaces, the scoping disciplines of mobile agents, etc. 
In other words, Klaim nets provide the distributed infrastructure to coordinate 
processes that access and share resources over a highly distributed system. 

Klaim exploits a capability-based type system to specify and enforce access 
control policies. Capabilities provide information about the intentions/rights of 
processes: reading/consuming tuples, producing tuples, activating processes, and 
creating new nodes. Capabilities have a hierarchical structure; for example we 
assume that a processes authorized to consume a tuple has also the right of 
reading it. The hierarchy of capabilities is reflected in the subtype relation over 
access types. The underlying idea is that if a process P has access type acl and 
this is a subtype of ac2 then P could be granted access type ac2 as well. In 
other words, P can be safely used in all contexts where a process of type ac2 
is expected. The (access) type of a process specifies the operations the process 
intends to perform at the localities of a net. The (access) type of a node specifies 
the access control policy of that node with respect to the nodes of the nets. 

Enforcement of access control policies is performed by the type checker which 
controls that the loaded software modules match the access policies of the nodes. 
Only processes (stationary or mobile) that have successfully passed the type 
checking phase can be executed. 

The clear distinction between specification and enforcement of access control 
policies is a key design element of the type system. Indeed, the development of 
Klaim applications proceeds in two phases. 

In the first phase, processes are programmed while ignoring the precise phys- 
ical allocations of tuple spaces and the access rights of processes. By exploiting 
type annotations and mechanisms for code inspection, a type inference system 
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assigns types to processes and checks whether processes behave consistently with 
their type declarations. 

In the second phase, processes are allocated over the nodes of the net. It is 
in this phase that access control policies are set up as a result of a coordination 
activity among the nodes of the net. 

This paper illustrates the Klaim access control model and shows how a 
capability-based type system is a useful and effective tool to write secure network 
applications. The main features of the approach are summarized below. 

— Access rights are explicitly recorded in type specification, thereby providing 
declarative specifications of access control policies. 

— Subtyping of access rights: alternative access policies can be defined by re- 
placing the default policy with a new, more restrictive policy that is a sub- 
type of the default policy. 

— Mobile processes are typed by their access control requirements; these are 
automatically generated by the type inference procedure. 

— Processes access control requirements are clearly separated from nodes access 
control policies: the node access control policy is formulated by the authority 
(the owner) of the node and is dynamically enforceable at run-time. 

— Klaim type system is sufficiently powerful to express access patterns of 
policies for customizing and confining the route of process migration. 

Figure 1 below, illustrates the basic ingredients of our approach. 




Access Types 



Process Type Site Type 

Inference Assignment 




Static (sub)Type 
Checking 




Pattern-Matching 



Dynamic (sub)Type 
Checking 



Fig. 1. Klaim type system: main ingredients 



The language and the design philosophy underlying Klaim are presented 
in [13]. The mathematical foundations (decidability and soundness) of the kernel 
of Klaim type system can be found in [15] (a preliminary presentation appeared 
in [12]). The prototype implementation of the language is described in [2]. 

The rest of the paper is organized as follows. In the next section we briefly 
review Klaim and its capability-based type system. Section 3 illustrates how 
Klaim primitives allow programming of complex interaction protocols; more 
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specifically, we consider three well-known paradigms for distributed computing, 
namely, mobile agent, code-on-demand and remote evaluation. We also show 
how the capability-based type system can be exploited to address the security 
needs of the three paradigms. Section 4 shows how the run-time type-checking 
mechanisms of Klaim can be exploited to impose access control policies. In 
particular, we show how to impose restrictions on mobile processes concerning: 

— the access to tuples from one or more localities; 

— the exchange of tuples among groups of localities; 

— the trajectory of process migrations. 

The final section summarizes our approach and suggests future extensions. 



2 The Klaim Programming Model 

We begin this section by summarizing the Linda programming model. Then, 
we introduce the main features of Klaim by means of simple examples. The 
complete syntax of the language is reported in the Appendix A. 

Linda is a coordination language that relies on an asynchronous and asso- 
ciative communication mechanism based on a shared global environment called 
Tuple Space (TS). A tuple space is a multiset of tuples, that are sequences of ac- 
tual fields (expressions or values) and formal fields (variables). Pattern-matching 
is used to select tuples in a TS. Linda provides four main primitives for handling 
tuples: two (non-blocking) operations add tuples to a TS, two (possibly blocking) 
operations read/ withdraw tuples from the TS. The Linda asynchronous com- 
munication model allows programmers to explicitly control interactions among 
processes via shared data and to use the same set of primitives both for data 
manipulation and for process synchronization. 

2.1 Nets and Processes 

We now introduce the Klaim primitives without considering typing issues. 
Klaim programs are structured around the notions of localities, tuples, tuple 
spaces, nets and processes. 

Localities (l , 1 ’ , . . . ) can be thought of as the symbolic names for sites. 
Sites (s , s’, . . . ) are the addresses (network references) of nodes. The bindings 
between localities and sites are stored in the allocation environment of each node 
of the net. Existence of a distinguished locality self is assumed: the self locality 
is used by processes to refer to their current execution site. 

Tuples contain information items; their fields can be actual fields (i.e. ex- 
pressions, localities, processes) and formal fields (i.e. variables). Syntactically, a 
formal field takes the form !ide, where ide is an identifier. For instance, the 
sequence (’ ’foo’ ’ , 25, !u) is a tuple with three fields. The first two fields 
are basic values (a string value and an integer value) while the third field is a 
locality variable. Similarly, (Agent<Itiiierary , RetLloc>, !List, Site) is a 
tuple whose first field is a process (with two parameters) . 
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Tuple spaces are collections (multisets) of tuples. Pattern-matching is used 
to select elements from a tuple space. Two tuples match if they have the same 
number of fields and corresponding fields have matching values or variables. 
Variables match any value of the same type, and two values match only if they 
are identical. 

Klaim nets provide the infrastructure to coordinate users accessing and shar- 
ing a set of resources over a configurable distributed system. Nets are sets of 
nodes; each node consists of a site s, an allocation environment e, a set of run- 
ning processes P and a tuple space T. Sites stand for physical places with a 
boundary (e.g. host machines, firewalls, administration domain). 

A node (an active Klaim abstract machine) embodies both the active com- 
putational units (processes) and the resources (tuples). Klaim communication 
paradigm is anonymous (tuples have no name) and associative (tuples are con- 
tent addressable). This form of communication mechanism has been recognized 
as a suitable tool to program network services where the set of available services 
(coded as tuples in the tuple spaces) at any given moment may dynamically 
change (see [1,23]). 

Technically, tuple spaces are modelled as processes emitting tuples, namely 
processes of the form out(t) where t is an evaluated tuple, i.e. a tuple where all 
fields are ground (they do not include variables). For instance, out(’ ’foo’ ’ , 
1) defines the tuple ( ’ ’ f oo ’ ’ , 1) . 

The allocation environment e constraints network connectivity: it basically 
behaves as a proxy mechanism for the processes allocated at a certain node. 

The following code 



node s : : e {P I T} 

defines a node, where s is the site, e the allocation environment, P the set of 
running processes and T the tuple space. Similarly, the following code 



node 


si : 


: el 


{PI 


Tl} 


node 


s2 : 


: e2 


{P2 


T2} 


node 


s3 : 


; e3 


{P3 


T3} 



defines a net with 3 nodes. 

Processes are the active computational units. They can perform five different 
basic operations, called actions, that permit reading from a tuple space, with- 
drawing from a tuple space, writing in a tuple space, activating new threads of 
execution and creating new nodes. 

The operation for retrieving information from a node has two variants: 
in(t)@l and read(t)@l. Action in(t)@l evaluates the tuple t and looks for 
a matching tuple t’ in the tuple space located at 1 (1 is the logical address 
of the tuple space). Whenever the matching tuple t’ is found, it is removed 
from the tuple space. The corresponding values of t ’ are assigned to the vari- 
ables in the formal fields of t and the operation terminates; the new bindings 
are used by the continuation of the process that has executed in(t)@l. If no 
matching tuple is found, the operation is suspended until one becomes available. 
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Action read(t)@l differs from in(t)@l only because the tuple t’ selected by 
pattern-matching is not removed from the tuple space. 

The operation for placing information on a node has, again, two variants: 
out (t) @1 and eval (P) @1. The operation out (t) @1 adds the tuple resulting from 
the evaluation of t to the tuple space located at 1. The operation eval(P)@l 
spawns a process (whose code is given by P) at the node located at 1. 

The operation for creating new nodes is newloc which takes as arguments 
a list of locality variables. For instance, newloc (ul, u2, u3) dynamically cre- 
ates 3 distinct new sites that can only be accessed via locality variables ul, u2, 
u3. 

Notice that variables occurring in Klaim processes can be bound by actions. 
More precisely, the actions in(t)@l and read(t)@l act as binders for variables 
in the formal fields of the tuple t. The action newloc binds the locality variables 
taken as arguments. 

We now provide some simple examples of Klaim programs; more advanced 
programming examples will be presented later. 

Klaim provides two mechanisms of mobility. The action eval moves a process 
code to a remote site “cutting” the links to the local resources, i.e. by adopting a 
dynamic scoping discipline. The action out can move a piece of code to a remote 
site while maintaining the links to the resources allocated at the original site, 
i.e. by adopting a static scoping discipline. 

Our first example illustrates a process that moves along the nodes of a net 
with a fixed binding of localities to sites. We consider a net consisting of two 
sites si and s2. A client process Client is allocated at site si and a server 
process Server is allocated at site s2. The server process can accept clients for 
execution. The client process sends process Q to the server. This is implemented 
by the following code: 

def Client = out (Q) @11 ; nil 

def Q = in(’’foo’’, !x)@self; out(’’foo’’, x+l)@self; nil 
def Server = in(!X)@self; eval(X)@self ; nil 

The behaviour of the above processes depends on the meaning of 11 and self. 
It is the allocation environment that establishes the links between localities and 
sites. Here, we assume that the allocation environment of node si, namely el, 
associates self to si and 11 to s2, while the allocation environment of site s2, 
e2, associates self to s2. Finally, we assume that the tuple spaces located at si 
and s2 both contain the tuple ( ’ ’ f oo ’ ’ , 1) . The following Klaim code defines 
the net outlined above: 

node si :: el { Client I out(’’foo’’, 1)} II 
node s2 :: e2 { Server I out(’’foo’’, 1)}. 

The client process Client sends process Q for execution at the server node 
(locality 11 is bound to s2 in the allocation environment el). After the execution 
of the action out(Q)@ll, the tuple space at site s2 contains a tuple where the 
code of process Q is stored. Indeed, the process stored in the tuple is 
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Q’ = in(’’foo’’, !x)@sl; out(’’foo’’, x+l)@sl ; nil 



because the localities occurring in Q are evaluated using the environment at si 
where the action out has been executed. Hence, when executed at the server’s 
site the mobile code increases the tuple at the client’s site. Fig. 2 gives a pictorial 
representation of this alternative. 
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Fig. 2. Agent Mobility: Static Scoping 



Our second example illustrates how mobile agents migrate with a dynamic 
scoping strategy. In this case the client process Client is defined by the code 
eval (Q) @11 ; nil. When action eval (Q) @11 is executed, the code of the process 
Q is spawned at the remote node without evaluating its localities according to 
the allocation environment el. Thus, the execution of Q will depend only on the 
allocation environment e2 and, hence, Q will increase the tuple at the server’s 
site. Fig. 3 illustrates this alternative. 
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Fig. 3. Agent Mobility: Dynamic Scoping 
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2.2 Types for Access Control 

Klaim makes use of a capability-based type system to express and enforce access 
control policies. Capability-based types provide information about permissions 
of processes: downloading/consuming tuples, producing tuples, activating pro- 
cesses, and creating new nodes. 

We use {r, i, o, e, n}to indicate the set of permissions, where each 
symbol stands for the operation whose name begins with it (e.g. r denotes the 
permission of executing a read action). 

The type Bottom is used to express no requirement (no action) by processes. 
Conversely, the type Top denotes the intention of performing any kind of op- 
erations. Moreover, atype and ttype denote access types and tuples types, 
respectively. 

A type of the form 1 — > r [ttype] — > Bottom, an arrow type, describes 
the permission/intension of performing, at location 1, the action of reading a 
tuple of type ttype without imposing any further constraint on the remaining 
process (the continuation). The arrow type 1 — > e — > atype describes the 
permission of executing of process of type atype at location 1. We often adopt 
the name capability to indicate the action permission of arrow types. For instance, 
r [int , string] is the capability of the arrow type 1 — > r [int , string] — > 
Bottom. 

The union type “atype , atype” is used to join permissions. Recursive types 
are used for typing migrating recursive processes (we often use ’ a to denote type 
variables) . 

In general, permissions have a hierarchical structure: a process authorized to 
read a tuple with a real value has also the right of reading a tuple with an int 
value. Similarly, a process authorized to perform an in action may also perform 
a read action. The hierarchy of access rights is reflected in the subtype relation. 
The underlying idea is that if a process P has type acl and acl is a subtype of 
ac2 then P could be considered as having type ac2 as well. In other words, P can 
be safely used whenever a process of type ac2 is expected. 

The subtype relation ^ formalizes this intuition. The type Bottom seman- 
tically corresponds to the smallest type, and the type Top denotes the greatest 
type. Several typing judgments formally characterize the subtype relation. For 
instance, the following clause 

1 — > r[int] — > Bottom ^ 1 — > r[real] — > Bottom 
states that a process looking for a tuple with an integer field can also be viewed as 
a process looking for a tuple with a real field. Motivations and formal properties 
of the subtype relation ^ can be found in [15]. 

Klaim tuples are typed. Tuple types basically are record types. The distin- 
guished tuple type any is used to have a form of genericity of tuples. 

To express user-based access policies, localities and locality variables may 
be annotated with type specifications which are pairs of the form (A, ac) called 
access lists that are lists of bindings from localities to capabilities. The distin- 
guished locality all is used to denote all nodes of a net. Access lists are exploited 
for different purposes: 
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— To restrict the kind of actions that a process can perform at (the site corre- 
sponding to) a specific locality that is transmitted in a tuple. 

— To specify the access rights of newly created nodes with respect to the nodes 
of the net, and the vice versa. 

— To specify the permissions of a process on actual arguments of process defi- 
nitions. 

Access types are also used to define the access control policy of nodes. For 
instance, the following access type, where ac and ac’ are access types and tuple 
types respectively, describes the access policy of node s, i.e. the permissions of 
processes located at s 

s — > n — > Bottom, 

si — > e — > ac, 

s2 — > r[int] — > Bottom, 

s3 — > r[bool,int] — > Bottom, 

s3 — > o[ac’] — > Bottom 

For example, a process located at s is allowed to spawn a process of type ac 
at site si and it is not allowed to perform any other action at site si. Nodes 
access types have a natural representation as labelled graphs. The following 
graph represents the access type described above. 




We now give a description of the use of types for access control. Let us con- 
sider a system consisting of a process Server and two identical Client processes. 
The server process 

def Server = out(l;<void, Top>)@self; nil 

adds a tuple, containing locality 1, to its local tuple space and evolves to the 
terminated process nil. In our example the server process does not take advan- 
tage of the possibility of imposing further restrictions on the access policy of 1: 
the pair <void, Top> states that the access restrictions at 1 are left unchanged. 
The client process 

def Client = read( ! u; < [self — > e] , ac>)@l-S ; 
eval(P)@u ; nil. 
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first accesses the tuple space located at 1-S to read an address. Then, it assigns 
the value read to the locality variable u and, sends process P for execution at 
u. The pair < [self — > e] , ac> specifies that Client needs a locality where it 
is possible to send for execution a process with (access) type ac from the site 
where Client is running^. 

Let us now consider a net where Server is allocated at site s and the two, 
identical. Client processes are at sites si and s2, where 1-S is bound to s to 
allow clients to interact with the server. 

Under the assumption that code P does not violate the access requirements 
specified by the access type ac (i.e. the type inferred for P is a subtype of ac), 
the inference system determines the following type c for the process Client 

c = 1-S — > r[<[self — > e] , ac>] — > Bottom 

This type c is an abstraction of Client behaviour stating that the process aims 
at reading the address of a node where a code of type ac is allowed to run. 

Notice that an important part of the programming task consists of adding 
type annotations to the code in order to specify the access policies. Our inference 
system inspects the annotated code to automatically determine the access policy 
requirements of the code. 

Let us consider our running example and assume the following types for the 
permissions associated to the sites si and s2 where Client is allocated: 

ac-sl = s — > r[<[self — > e] , acl>] — > Bottom 
ac-s2 = s — > r[<[self — > e] , ac2>] — > Bottom 

Both permissions state that a process can be executed at the address read at 
site s. However, in the case of site si processes with privileges smaller that acl 
can be executed at the read address; while processes with type smaller than ac2 
can be executed in the case of site s2. 

The enforcement is performed by the type checker that verifies that the types 
of the processes loaded on a node are valid instances of the type which specifies 
the access control policy of the node. Processes are allocated and executed only 
if they are accepted by the type checker. In the type checking phase, the type 
of the process is obtained by evaluating its localities according to the allocation 
environment of the site where the process is allocated. Hence, access requests 
for sites which are not “visible” from the node lead to type failures. 

In our running example assume that cl and c2 are the instances of the type 
of the Client process in sites si and s2, respectively. Further, assume that cl is 
a subtype of ac-sl and that c2 requires more privileges than ac-s2 then, only 
the Client process at site si successfully passes the type checking phase and 
has the right of reading tuples at the server’s site and, consequently, of sending 
processes for execution. 

^ In Klaim self is a reserved keyword that indicates the current execution site 
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3 Paradigms for Mobility 

Mobile Code Applications are applications running over a network whose distinc- 
tive feature is the exploitation of forms of “mobility”. According to the classi- 
fication proposed in [9], we can single out three paradigms that, together with 
the traditional client-server paradigm, are largely used to build mobile code ap- 
plications. These paradigms are: Mobile Agent, Code- On- Demand and Remote 
Evaluation. 

The first paradigm can be easily implemented in Klaim by using the actions 
eval or out, in dependence on the chosen binding strategy (dynamic or static, 
respectively) adopted for localities. We did comment on this at the end of Sec- 
tion 3. In the rest of this section, we analyze the two remaining paradigms with 
specific attention devoted to the security aspects. 

Code- on- Demand A component of an application running over a network at a 
given node, can dynamically download some code from a remote node to perform 
a given task. 

To download and execute code stored in the tuple space located at 1 with 
certain access privileges (specified by the access type ac), we can use the process 

read(!X:ac)@l ; eval(X)@self ; nil. 

The downloaded code is checked for access violations at run-time by the 
pattern-matching mechanism that checks the types of processes to ensure that 
they satisfy the type annotations specified by the programmer. Hence, process 
codes are checked before being downloaded. In other words, the pattern-matching 
operation performs a run-time type checking of incoming codes. 

Remote Evaluation A component of a network application can invoke services 
from other components by transmitting both the data needed to perform the 
service and the code that describes how to perform the service. 

To transmit both code P and data v of type bt at the locality 1 of the server, 
we can use the code 

out(in( !y:bt)@l ; A<y>, v)@l 

where def A(x) = P. 

Here, we assume that the server adopts the following (code-on-demand) pro- 
tocol 

in(!X:ac, !x:bt)@self; out(x)@self; eval(X)@self ; nil 

To prevent “damages” from P, the server loads and executes code P only if the 
instance of the type of the code is a subtype of ac. Again, dynamic type checking 
is extensively used to ensure that dynamically executable codes adhere to the 
access policy of the node. 

Type ac may give only minimal access permissions on the server’s site, for 
instance, only the capability of reading a tuple consisting of a string and an 
integer value, and giving back the results of the execution. In this case, the 
access type is of the form 
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s — > r [string, int] — > Bottom, 
sO — > o [string, int] — > Bottom, 
si — > o [Top] — > Bottom 

where s is the server’s site and sO is the site which invokes server’s facilities and 
si is another site. 

Notice, however, that this does not prevent P from visiting other sites. In 
particular, code P may be programmed in such a way that it transmits some 
code Q with access type ac-Q at 11: 

def P = read( !y: string, !x:int)@l ; 
out(op2(y), opl (x) )@self ; 
out (Q) @11; nil 

It is immediate to see that the instance of the type of code P at the server site is 

s — > r [string, int] — > Bottom, 
sO — > o [string, int] — > Bottom, 
si — > o [ac-Q] — > Bottom 

Hence, the instance of the code P satisfies the access policy of node sO. How- 
ever, code Q is only stored in the tuple space at si, no new thread of execution 
is activated at that site. Before being executed code Q must be read and verified 
(dynamic type checking). Therefore, process P cannot silently activate a Trojan 
horse at the remote site si. 

4 Controlling Use of Resources 

In the previous section, we examined the support offered by the Klaim capabil- 
ity-based type system for access control by considering well-known paradigms of 
mobility. In this section, we show how to exploit Klaim capability-based types to 
restrict the resources usage within a net. In particular, we show that Klaim types 
are powerful enough to program and enforce policies which are usually handled 
by low-level techniques (e.g. sand-boxing and firewall). Moreover, the explicit 
typing of sites can be also used to define policies which limit mobile processes 
to specific route. 

Restricting Interactions Klaim action primitives operate on the whole net not 
just at the process current site. From the point of view of security mechanisms, 
communications among different sites of the net (i.e. remote communications) 
could be controlled and regulated. This corresponds to place over a node a form 
of sandboxing which treats all processes as potentially suspicious. 

For instance, to make sure that a process running on a certain site s gets only 
local information, it suffices to constrain the type specifying the access control 
policy of the node to allow local communications only. 

To this purpose, it suffice to state that for no site s’ different from s, the 
types’ — > r[any] — > Bottom (or any of its subtypes) is a subtype of ac-s. 
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the access type of site s. Hence, a process P allocated at site s that is willing to 
perform remote read/in operations violates the access rights. To access tuples at 
a remote tuple space, a well- typed process must first move (if it has the required 
rights) to the remote site. Using a similar strategy also output actions can be 
forced to be local. 

Firewall We now show how to specify a firewall by means of suitable typing. 
The idea is that the type of the site where the firewall is allocated specifies the 
access policy of network services. Assume that the firewall is set up at site s to 
protect sites s-1, . . ., s-n from sites S-1, . . ., S-m. 

A first requirement is that processes located at site S-j cannot directly in- 
teract and ask for services at any site s-i. To this purpose we impose that for 
each site S-j it cannot be the case that s-i — > cap — > Bottom, where cap 
is any capability, is a subtype of the access type of the node (ac-S-j). 

On the other hand, type ac-S-j may have subtypes of the form 

s — > o [any] — > Bottom, 

since each site S-j may send service requests to the firewall. Here we assume 
that the service request is stored in a tuple and we do not impose any restriction 
on the type of the tuple. This setting guarantees that all connections from sites 
S-1, . . ., S-m to sites s-1, . . ., s-n have to pass through site s, the firewall. 

For instance, process 

def P = out(eval(Q)@s-i)@s ; nil 

complies with the access control policy, while process 

def P’ = eval(Q)@s-k ; nil 

violates the access control policy of site s-k. 

The firewall can be programmed to handle the requests according to cer- 
tain policies. Typically, the firewall handles a service request according to the 
following pattern 



read (! Request ;ac-r) ; <RequestHandler> 



where type ac-r specifies the access policy that the service request must satisfy. 
For instance, if 

ac-r = s-1 — > i [any] — > Bottom, 

s-2 — > e — > (s-2 — > r[any] — > Bottom, 

S-k — > o [any] — > Bottom) 

then the two service requests 

eval(read( ! X : int)@self ; out(op(x))@S-k ; nil)@s-2 ; nil 
read( ! X : int)@s-l ; nil 



both satisfy the type requirements and will be accepted. The service request 
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read( ! X : int)@s-l ; out(op(x))@S-k ; nil 

violates the access policy and will be rejected. 

The examples above do not specify any constraint on the tuples read. More 
refined access policies can be obtained by specifying the type of tuples. For 
instance, one can fix a policy where the read operations are constrained to get 
from the tuple space only ‘plain’ data tuples, namely tuples without localities 
or process codes. 

Klaim applications might need to define their own firewall, i.e. a user node 
which acts as a filter for the network traffic, without changing the default policies 
of the nodes of the net. Let us consider, for instance, the following user process: 

def P = newloc(u-l: <al-l, ac-l>, 
u-2: <al-2, ac-2>, 
u-F : <al-F, ac-F>) ; 

<Firewall Handler> 

Now, assume that both access lists al-1 and al-2 are of the form 

[u-F — > cap] 



for a suitable capability cap. 

Process P creates a subnet whose sites are associated to locality variables u-1 
and u-2 and the type annotations ensure that the subnet can be reached only 
through site u-F (the firewall) . The user process specifies in the type specification 
of locality u-F the access policy to the firewall. For instance, setting al-F = 
[self — > o[any]] means that the firewall site can be accessed only from the 
site where the user process is running. 

Fares and Tickets A primary access control policy consists of controlling the 
route of a mobile agent traveling in the net. For instance, if one has to configure 
a set of sites with new software, a mobile agent can be programmed to travel 
among the sites to install the new release of the software. 

If the starting site of the trip is site s-0 and sites s-1, s-2, . . ., s-n have to 
be visited visited before getting back to the starting site, the following type can 
be used to specify the access policy of the trip: 

ac-0 = ac, s-1 — > e — > ac-1 
ac-1 = ac, s-2 — > e — > ac-2 

ac-n-1 = ac, s-n — > e — > ac’ 
ac’ = s-0 — > o [string] — > Bottom 

The idea is that at each site type ac specifies the allowed operations (e.g. in- 
stalling the new release of a software package); the remaining type information 
specifies the structure of the trip (which is the next site of the trip). When it 
reaches the last site of the trip, the agent has the rights of returning to the 
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original site the results of the trip (e.g. the notification that the installation was 
successful) . 

The type discussed above can be properly interpreted as the fare of the trip: 
an agent M can perform the trip provided that its type matches the fare, namely 
its instance at site s-0 is a subtype of the type of the trip. Notice that this 
ensures that a malicious agent cannot modify the itinerary of the trip to visit 
sites other than those listed in its ticket. 

5 Concluding Remarks 

We have described the security architecture of the experimental network pro- 
gramming language Klaim. This language provides users with a programmable 
support to configure application-specific access control policies by exploiting a 
capability-based type system. Although, the type system we designed is tailored 
to the Klaim language, the general spirit of the approach can be applied to 
define types for access control of programming languages for highly distributed 
systems. We summarize below the main points: 

— Declarative specification of access control policies via type annotations and 

type inference. 

— Structured hierarchy of access rights based on subtyping. 

— Clear separation of process requirements from node requirements. 

— Static and dynamic type checking. 

— Programmability and customization of access control policies. 

The prototype implementation of Klaim [2] is built on top of Java and Java 
security architecture (the sandbox model) . The implementation of Klaim access 
control models (in Java version 1.2) is in progress, however preliminary imple- 
mentations have been already exploited to validate some design choices of the 
type system. 

We plan to extend Klaim access types to handle history dependent access 
control. In history dependent access control access requested are granted on 
the basis of what happened in the past of the ongoing computation. Moreover, 
the development of network applications raises other issues related to security. 
We plan to integrate in Klaim other security mechanisms (both at the foun- 
dation level and at the implementation level). These include mechanisms for 
secure communication and authentication, and agent code security. As for re- 
lated work, we do refer the interested reader to [14] where specific comments 
on [3,4,8,6,7,16,17,19,20,21,22] can be found. 
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A Klaim Syntax 

Basic Types 

btype ::=int I real I string I bool I ... 

Field Types 

ftype : = btype I <alist , atype> I atype 

Tuple Types 

ttype : : = ftype I any I ftype , ttype I ttype , ftype 

Access Lists 

alist : : = void I [1 — >e] I [1 — >n] I [1 — > r [ttype] ] I 
[1 — > i [ttype] ] I [1 — > o [ttype] ] I 
[all — >e] I [all — >n] I [all — > r [ttype] ] I 
[all — > i [ttype]] I [all — > o [ttype] ] I alist, alist 

Access Types 

atype ::= Bottom I Top I 1 — > r [ttype] — > Bottom I 

1 — > i [ttype] — > Bottom I 1 — > o [ttype] — > Bottom I 
1 — > n — > Bottom I 1 — > e — > atype I 
atype, atype I ‘a I rec 'a atype 

Locality Patterns 

[pattern ; : = u : <alist , atype> I u : <alist , atype> , [pattern 

Actions 

Act :: =out(t)@L I in(t)@L I read(t)@L I eval(P)@L I 
newloc ([pattern) 

Processes 

P :: =nil I Act ; P I P I P I A<P, L, v> 

Agent Definitions 

A : := def A(P,L,v) = P 

Evaluated Tuples 

T := out(t) I T I T 

Nets 

N : := node s : : e { P I T } where atype I N I I N 

Tuples 

t : := f I (f , t) 

Fields 

f : : = V I P I 1 : <alist , atype> I 

!x:btype I !X:atype I !u:<alist, atype> 
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Model checking is emerging as a practical tool for automated debugging of re- 
active systems such as embedded controllers and network protocols [9,11]- Since 
model checking is based on exhaustive state-space exploration, and the size of 
the state space of a design grows exponentially with the size of the descrip- 
tion, scalability remains a challenge. The goal of our recent research has been 
to develop techniques for exploiting the modular design structure during model 
checking. Software design notations (e.g. Statecharts [10], Uml) provide rich 
constructs to facilitate modular descriptions. Instead of destroying this structure 
by compiling the descriptions into flat state-transition graphs, we are developing 
algorithms that are optimized for modular descriptions. In this talk, we sum- 
marize research concerning two different notions of hierarchy: architectural and 
behavioral. 

Architectural Hierarchy 

The hierarchical decomposition of a system architecture into subcomponents can 
be well described in the modeling language of Reactive Modules [4]. In this lan- 
guage, processes communicate via shared variables, and can be combined using 
the operations of parallel composition, instantiation, and variable hiding. The 
theory of reactive modules supports modular refinement, and the language is 
supported by the model checker Mocha (see www . cis . upenn . edu/ "mocha) . We 
consider three ways of exploiting the modular structure for automated verifica- 
tion: 

Hierarchic reduction. We have developed an on-the-fly reduction algorithm 
that exploits the visibility information about transitions in a recursive man- 
ner based on the architectural hierarchy [7]. 

Assume guarantee reasoning. Refinement checking corresponds to trace 
containment between implementation and specification modules. Compo- 
sitional and assume-guarantee proof rules allow for decomposing the refine- 
ment check into subproblems, and are integrated in the model checker. 
Games. The requirements are expressed as formulas of Alternating Temporal 
Logic [5] , which allows the formal specification of requirements that refer to 
collaborative as well as adversarial relationships between modules. The game 
semantics of ATL allows the construction of the most general environments 
of individual components, which can be exploited to automate modular ver- 
ification [1]. 
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Behavioral Hierarchy 

The control structure for the behavior of an atomic component can be described 
hierarchically in the modeling language of Hierarchical Modules [2] . The language 
has powerful features such as nested modes, mode reuse, exceptions, group tran- 
sitions, history, and conjunctive modes, and is being implemented in the model 
checker HeRMes. We survey three related research directions: 

Complexity and expressiveness. Due to sharing of modes, flattening of a 
hierarchical state machine causes an exponential blow-up. Recent research 
has results on succinctness of hierarchical construct, the complexity of oper- 
ations such as emptiness and equivalence, and algorithms for model checking 
linear-time and branching-time requirements [8,6]. 

Modular refinement. While in the style of Statecharts in spirit. Hierarchi- 
cal Modules have well- typed entry- and exit-points, and communication via 
variables with standard scoping rules. These features allow for a composi- 
tional trace semantics for modes that supports a refinement calculus with 
assume-guarantee proof rules [2]. 

Model checking. We have developed heuristics for enumerative as well as sym- 
bolic reachability analysis of hierarchical modules that exploit the scoping 
of variables and stack-like structure of individual states [3] . 
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Abstract. We present two process frameworks: the action calculi of Mil- 
ner, and the fusion systems of Gardner and Wischik. The action calculus 
framework is based on process constructs arising from the 7r-calculus. 
We give a non-standard presentation of the 7r-calculus, to emphasise the 
similarities between the calculus and the framework. The fusion system 
framework generalises a new process calculus called the up -calculus. We 
describe the TTF-calculus, which is based on different process constructs 
to those of the yr-calculus, and show that the generalisation from the 
calculus to the framework is simple. We compare the frameworks by 
studying examples. 



1 Introduction 

Our aim in studying process frameworks is to integrate ways of reasoning about 
related interactive behaviour. The purpose is not to provide a general, all- 
encompassing system for describing interaction — that would miss the point that 
there are many kinds of interactive behaviour worth exploring. Rather, the aim is 
to study interaction based on some fixed underlying process structure. A process 
framework consists of a structural congruence, which establishes the common 
process constructs used in the framework, and a reaction relation which describes 
the interactive behaviour of particular processes specified by a signature. The 
higher-order term rewriting systems have a similar format; the structural con- 
gruence describes the higher-order features given by the A-terms with /3-equality, 
and a rewriting relation describes the reaction between terms generated from a 
signature. 

In this paper, we describe two process frameworks: the action calculi of 
Milner [Mil96], and the fusion systems of Gardner and Wischik [GW99]. The 
action calculus framework is based on process constructs arising from the tt- 
calculus. We give a non-standard presentation of the 7r-calculus, to emphasise 
the similarities between the calculus and the framework. We also present the 
fusion system framework which generalises a new process calculus, called the 
TTp -calculus [GWOO], in much the same way as the action calculus framework 
generalises the 7r-calculus. The Tr^-calculus is similar to the 7r-calculus in that 
its interactive behaviour is based on input and output processes, and different in 
that its underlying process structure is not the same. We describe the Tr^-calculus 

* The author acknowledges support of an EPSRC Advanced Fellowship. 



C. Palamidessi (Ed.): CONCUR 2000, LNCS 1877, pp. 69-88, 2000. 
(c) Springer- Verlag Berlin Heidelberg 2000 



70 



Philippa Gardner 



and the fusion system framework, and illustrate that the generalisation from the 
calculus to the framework is simple. We also compare the two frameworks by 
studying specific examples. 

1.1 Prom the tt- C alculus to Action Calculi 

We describe the transition from the 7r-calculus to the action calculus frame- 
work. By adapting Milner’s presentation of the 7r-calculus in [Mil99], we show 
that this transition is comparatively simple. Instead of the input and output 
processes specific to the 7r-calculus, an action calculus consists of more flexible 
control processes. The interactive behaviour of such control processes is given by 
a reaction relation specific to the particular action calculus under consideration. 
The other constructs of an action calculus are essentially the same as those of 
our TT-calculus, except that there is no restriction. Instead the 7r-process {vx)P 
is interpreted by an action process new • {x)P, where the control process new 
blocks the access to the name-abstraction. We explore two examples of action 
calculi: the tt action calculus corresponding to the 7r-calculus, and the action 
calculus corresponding to a call-by-value A-calculus. These examples illustrate 
that the basic process constructs for action calculi are indeed natural. We also 
refer to recent results of Leifer and Milner [LMOO] , who provide general bisimu- 
lation congruences for (simple) reactive systems and aim to extend their results 
to action calculi. 

1.2 The TTi^-Calculus 

The TTp-calculus is similar to the 7r-calculus in that it consists of input and 
output processes that interact with each other. It is different from the 7r-calculus 
in the way that these processes interact. In a 7r-reaction, the intuition is that 
names are sent along a channel name to replace the abstracted names at the 
other end. In contrast, the 7ri?-calculus does not have abstraction. Instead, a irp- 
reaction is directionless with names being fused together during reaction. This 
fusion mechanism is described using a explicit fusion (z = y), which is a process 
declaring that two names can be used interchangeably. A natural interpretation 
is that names refer to addresses, with explicit fusions declaring that two names 
refer to the same address. 

The TTp-calculus is similar in many respects to the fusion calculus of Parrow 
and Victor [PV98], and the x-calculus of Fu [Fu97]. The key difference is how the 
name- fusions have effect. In the TTi^’-calculus, fusions are explicitly recorded and 
have effect though the structural congruence. This has the consequence that the 
TTir-reaction is a simple local reaction between input and output processes. In the 
fusion calculus on the other hand, fusions occur implicitly within the reaction 
relation. This outcome of this is a non-local reaction relation. 

We provide a natural bisimulation congruence for the 7ri?-calculus. We also 
have simple embeddings for the 7r-calculus, the fusion calculus and a call-by-value 
A-calculus in the TTp-calculus. Intriguingly, the A-embedding is purely composi- 
tional, in contrast with the analogous embeddings in the 7r-calculus and fusion 
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calculus. Further details can be found in [GWOO]. We summarise the results in 
this paper, using the examples of fusion systems described below. 



1.3 Fusion Systems 

The generalisation from the TTi^’-calculus to the fusion system framework is sim- 
ple. The basic process constructs and the definition of the structural congruence 
are the same. As with action calculi, fusion systems have the flexibility to describe 
other forms of interactive behaviour by adapting the input and output processes 
of the TTF-calculus to more general control processes. The interactive behaviour 
of the control processes is again given by a reaction relation, which is specific 
to the particular fusion system under consideration. We explore the irp fusion 
system, which corresponds exactly to the 7ri?-calculus, and the A„ fusion system 
which describes a call- by- value A-calculus. The A„ fusion system is a subsystem 
of the t:f fusion system. This simple relationship depends on the explicit fusions. 
It means that the bisimulation congruences for the TTir-system easily transfer to 
the A„-system. We are currently exploring a link between a bisimulation con- 
gruence for the A^-system and a corresponding behavioural congruence for the 
call- by- value A-calculus. It remains further work to provide general bisimulation 
results for fusion systems. However, this is not our primary concern. First, we 
would like to explore specific examples of fusion systems to illustrate the expres- 
siveness of explicit fusions. 

Acknowledgements The work on the TTi^’-calculus and fusion systems is joint 
with Lucian Wischik. 



2 From the tt Calculus to Action Calculi 

In [AIil99], Milner presents the 7r-calculus using a structural congruence which 
describes the underlying process structure, and a reaction relation which de- 
scribes the interaction between input and output processes. In particular, he 
builds processes using abstractions and concretions as interim constructs, and 
generates the reaction relation by the axiom 

x.P I x.Q \ P ■ Q, 

where the operator • is a derived operator expressing the application of a con- 
cretion to an abstraction. In contrast, we treat all the constructs in the same 
way. We consider the application operator as a primitive operator. Although 
it can be derived in the 7r-calculus, it cannot be derived in the action calculus 
framework. We regard abstractions as processes, but instead of the concretion 
{i/z){y)P for example, we have the process {yz){{y) | P) where the process (y) 
is called a datum. The reason for focusing on datums rather than concretions is 
that variables of the A-calculus translate to datums in the corresponding action 
calculus. The datums therefore seem more fundamental. 



72 



Philippa Gardner 



In order to define reaction precisely, we require the correct number of datums 
and abstractions to match. This information is given by the arity of the process. 
In general, the arity information can include quite complex typing information, 
such as the sorting discipline for the 7r-calculus given in [Mil99]. In this paper 
we keep the arity structure simple, and just use it to count abstractions and 
datums. 

There are two natural approaches for defining simple arities for 7r-processes. 
One approach keeps the abstractions and datums separate, so that we can form 
{x)P and {x) | P, but not (x){{x) |P). In this case, arities are integers with 
the positive numbers counting the abstractions and the negative numbers the 
datums. The resulting process algebra corresponds to the 7r-calculus presented 
in Milner’s book [Mil99]. The second approach mixes abstractions and datums, 
so that we have for example the process {x){{x) \ P). Arities have the form (m, n) 
for m,n,> 0, where m counts the abstractions and n the datums. We choose 
this second approach here, since it gives a smooth link to the action calculus 
framework. It remains further work however to fully justify the use of abstracted 
datums for the 7r-calculus. They are justified in the action calculus framework. 

Following our presentation of the 7r-calculus, the description of the action 
calculus framework is comparatively simple. An action calculus essentially con- 
sists of the same underlying process constructs as our 7r-calculus, except that it 
does not have restriction. The definition of the structural congruence has to be 
modified however to account for the more general behaviour of application in the 
framework. Instead of input and output processes, an action calculus consists of 
general control processes of the form AT(Pi, . . . , Pr) where the control K denotes 
some sort of boundary (or firewall) containing the processes Pi . The interactive 
behaviour of the control processes is described by a reaction relation. 

For example, the input and output processes of the 7r-calculus correspond to 
action processes of the form {x) ■ in(P) and {x) ■ out(P) respectively. The controls 
in and out are specific to the tt action calculus, and provide a boundary inside 
which reaction does not occur. Restriction is not primitive in the framework. 
Instead the restriction {i/x)P of the 7r-calculus is interpreted by new - {x)P where 
new is a control which blocks the access to the abstraction. 



2.1 The 7T- Calculus 

Throughout this paper, we assume that we have an infinite set N of names 
ranged over by u, . . . , z, and use the notation z to denote a sequence of names 
and |z| to denote the length of the sequence. 



Definition 1 

The set of pre-processes of the 7r-calculus is defined by the grammar 



P ::= 



nil Nil process 

P I P Parallel composition 

P ■ P Application 

(x) Datum 

{x)P Abstraction 
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{vx)P Restriction 
x.P Input Process 

x.P Output process 

The definitions of free and bound names are standard: the abstraction {x)P and 
the restriction (yx)P bind a; in P, and x is free in the processes {x), x.P and 
x.P. We write fn(P) to denote the set of free names in P. 

The application operator is used to apply the contents of input and output 
processes during reaction: 



x.P\x.Q\P-Q. 

To define reaction properly, we require the correct number of datums in P and ab- 
stractions in Q to match. This information is given by the arity of a pre-process. 
We write P : {m,n) to declare that a pre-process has arity where m 

and n are natural numbers counting the abstractions and datums respectively. 



Definition 2 

The set of n-processes of arity (m, n) is defined inductively by the rules 



nil : (0,0) 

P : (to, n) Q : (fc, 1) 

P\Q : {m + k,n + 1) 

P : (to, n) 

{x)P : (to -I- 1, n) 

P : (to, 0) 
x.P : (0,0) 



(x):(0,l) 

P : (to, k) Q : (fc, n) 

P ■ Q : (to, n) 

P : (to, n) 

{vx)P : (to, n) 

P : (0, to) 
x.P : (0,0) 



Definition 3 

The struetural eongruence between 7r-processes of the same arity, written =, is 
the smallest congruence satisfying the axioms given in figure 1, and which is 
closed with respect to _ | (a;)-, (i^a;)_ , x._ and x.-. 

Notice the side-condition associated with the axiom for the commutativity of 
parallel composition. It results in the order of abstractions and datums always 
being preserved, as one would expect. The other rules are self-explanatory. The 
application axioms are enough to show that application can be derived from the 
other operators. 

One property of the structural congruence is that every 7r-process is congruent 
to a standard form. Standard forms are processes with the shape 



{x){i^z){{y}\P), 
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Standard axioms for nil, _| _ and {vx)j. 

P\n\\ = P 
P\n\\ = P 

{P\Q)\R=P\{Q\R) 

P\Q = Q\P, P \ (m, 0), Q : (0, n) 

[vx){vy)P = [vy)[vx)P 
{vx){P\Q) = {vx)P\Q, X ^ fn(Q) 
{vx){P\Q) = P\{vx)Q, X ^ fn(P) 
(vx)P = {vy)P{y/x}, y ^ fn(P) 
(!^x)nil = nil 

Abstraction axioms: 



(x)P = {y)P{y/x}, y ^ fn(P) 

{vx)(y)P = {y){vx)P, y^x 
{x){P\Q) = {x)P\Q, x^fn(Q) 

(x)(P|g) = P|(x)Q, x^fn(P),P: (0,m) 

Application axioms: 

{vx){P ■ Q) = {vx)P ■ Q, X ^ fn(Q) 

{vx){P ■ Q) = P ■ {vx)Q, X ^ fn(P) 

{x)P-Q = {x){P-Q), x^fn(Q) 

{{y) I Q) ■ {x)P = Q ■ P{y/x} 

Q ■ P = Q\P, Q : (m, 0), P : (0, n) 

Fig. 1. The structural congruence between 7r-processes of the same arity, writ- 
ten =, is the smallest equivalence relation satisfying these axioms and closed 
with respect to contexts. 



where the xs and is are distinct, the is are contained in the ys, and P : (0, 0) 
does not contain any applications. Standard forms are essentially unique in the 
sense that, given two congruent standard forms 

(fi)(j/i'i)((yi) I Pi) = (X2)(vz2)({y2} | P 2 ), 

then |xi| = |x 2 | and |ii| = |i 2 |, the y\ and 2/2 are the same up to a-conversion of 
the xs and is, and Pi and P 2 are structurally congruent again up to a-conversion. 
Using the standard forms, application can be derived from the other operators. 

The reaction relation between 7r-processes of the same arity, written \, is 
the smallest relation generated by 



x.P\x.Q\P-Q, 
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where P and Q have arities (0,m) and (m, 0) respectively, and the relation is 
closed with respect to _ | and _ = 

In [Mil99], Milner defines a labelled transition system and the corresponding 
strong bisimulation for the 7r-calculus, using standard transitions with labels x, 
X and T. It is straightforward to adapt his definitions to our presentation. 



2.2 Action Calculi 

An action calculus is generated from the basic process operators of the 7r-calculus, 
except restriction, plus control operators specific to the particular action calculus 
under consideration. However, the definition of the structural congruence cannot 
be simply lifted from the corresponding definition for the 7r-calculus. In the 
TT-calculus, application is only used to apply datums to abstractions. In the 
framework, application is also used to apply control processes to other processes. 
This additional use of application requires a more general description of its 
properties. For example, the associativity of application can be derived in the 
TT-calculus, but must be declared explicitly in the framework. 

The simplest way to define the structural congruence for the framework is to 
adapt the basic constructs of the 7r-calculus to include the identity process id^, 
and the permutation process Pm,n, where m and n are arities. These constructs 
can be derived from the other operators: for example, we have idi = {x){x) and 
Pi I = (x,y){y,x) where y ^ x. We choose to regard them as primitive, since 
they play a fundamental role in the congruence definition. 

An action calculus is specified by a set 1C of controls, plus a reaction relation 
which describes the interaction between control processes. Each control K in /C 
has an associated arity ((mi,ni), . . . , (mr,nr)) which informs us that 

a control process K{P\, . . . , Pr) has arity (fc, 1) such that Pi has arity (mi, Ui). 

Definition 4 

The set T’ac(^) pre-processes of an action calculus specified by control set JC 
is defined by the grammar 



idjTj, 


Identity 


Pm,n 


Permutation 


P\P 


Parallel composition 


P P 


Application 


(x) 


Datum 


{x)P 


Abstraction 


K{Pi,. 


. . ,Pr) Control process 



The set Vac{IC) of action processes of arity (m,n), specified by control set /C, is 
defined by the identity and permutation axioms 



idm : (m,m) 



Pm,n : (m -h n,n -h m), 
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the appropriate rules in definition 2, and the control rule 

Pj : {mi,rii) i S {1, . . . ,r} 

K{P,,...,Pr) : (k,l) 

where control K has arity ((mi, ni), . . . , (m^, n^)) — *■ (k, 1). 

The axioms generating the structural congruence for the framework are a 
modification of the axioms for the 7r-calculus given in figure 1 of section 2.1, 
minus those referring to restriction. The best way to describe the axioms is to 
focus on the categorical structure of processes. An action process P : (m, n) can 
be viewed as a morphism in a category with domain m and codomain n. The id^ 
operator corresponds to the identity of the category, application to sequential 
composition, parallel to tensor, and Pm,n to permutation. The structural con- 
gruence on action processes is defined in figure 2. It is generated by the axioms 
of a strict symmetric monoidal category and two additional naming axioms. 

The axioms of a strict symmetric monoidal category just state that the iden- 
tity, parallel composition, application and permutation operators behave as we 
would expect. A possibility helpful intuition is that the processes ido and po,o 
correspond to the nil process and 

idm = {x){x), X distinct , |af| = m > 0 (1) 

Pm,n = {x, y){y, f), x,y distinct , |f| = m,\y\ = n, m + n> 0. 

For example, the last axiom generalises the commutativity of parallel compo- 
sition for the TT-calculus. The first naming axiom is just a special case of the 
application axiom for the 7r-calculus given in figure 1, which describes the appli- 
cation of datums to abstractions. The second naming axiom is a generalisation 
of the structural congruence given in (1) for the identity process. The appro- 
priate TT-axioms in figure 1 of section 2.1 are derivable from the axioms given 
here. With the above interpretation of the identity and permutation processes, 
the axioms of the framework are also derivable in the 7r-calculus. 

The reaction relation \ is a binary relation between action processes of the 
same arity, which is closed with respect to _ | , _ • _ , (a;)_ and _ = _. We specify 
whether reaction may occur inside controls. Both examples studied in this section 
prevent it. 

We have a very different type of standard form result for action calculi, since 
application plays such a prominent role. The standard forms are not special pro- 
cesses, but rather have a completely different notation to processes. We therefore 
call them molecular forms, to emphasise this difference and conform with the 
literature [Mil96]. The molecular forms are generated by the grammars 

Molecular forms P ::= {x)[M, . . . ,M](?/), x distinct 

Molecules M ::= {u)K{Pi, . . . ,Pr){v), v distinct 

with r, |it| and |n| determined by the arity of control K. The x and y correspond 
to the abstractions and datums in the standard forms for the 7r-calculus given 
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Axioms of a strict symmetric monoidal category: 



Pid„ = P 
P-{Q-R) = 

(A ■ P 2 ) I (gi • Q 2 ) = 



IU771 • 1 

(P-Q)-R 
{Pi\Qi)-{P 2 I Q 2 ) 



P I ido = P 
iP\Q)\R = 

idm I idri = 



= ido I P 

p|(g|p) 



idm- 



■n 



Pm,n ■ Pn,m 



Pm+n,fc 
Pm,n • (P I Q) 



idm-(-n 

(idm I Pn,fc) ■ (Pm,fe | idn) 

(Q I P) - pfc,/ , P : (m, /), Q : (n, k) 



Naming axioms: 



{{y) I id„>) • {x)P = P{y/x} 
{x){{{x} I idm) ■ P) = P, X ^ fn(P) 



Fig. 2. The structural congruence between action processes of the same arity, 
written =, is the smallest equivalence relation satisfying these axioms and closed 
with respect to contexts. 



in section 2.1, where (|i|, |?7|) is the arity of the molecular form. The u are free, 
and the v are distinct and bind to the right. These v provide the mechanism for 
recording the sequential dependency of control processes. The molecular forms 
have a simple structural congruence, given by a-conversion of bound names and 
the partial reordering of the molecules when there is no name clash. 



The 7T Action Calculus The tt action calculus is specified by the controls 

out : ((0, m)) ^ (1, 0) in : ((m, 0)) ^ (1, 0) new : ( ) — > (0, 1) 

The input and output processes correspond to the action processes of the form 
(x) ■ in(P) and {x) ■ out(P) respectively. Restriction is interpreted by action 
processes of the form new • {x)P, where the new control blocks the access to the 
abstraction. The reaction relation is generated by the rule 

(x) • out(P) I (x) • in(Q) \ P ■ Q 

where P and Q must have arities (m, 0) and (0,n) respectively and we specify 
that reaction does not occur inside the controls. 

The correspondence is not absolutely exact, since the 7r-axiom 

(j^x)nil = nil 

is not preserved by the translation. However, the translated processes are bisim- 
ilar. Apart from this point, it is not difficult to show that the structural congru- 
ence and the reaction relation are strongly preserved by the embedding [Mil96]. 
These results rely on the molecular forms described earlier. 
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The A„ Action Calculus The Ay action calculus interprets A-terms as pro- 
cesses of arity (0, 1). It is specified by the controls 

lam : ((1,1)) ^ (0,1) ap:()^(2,l). 

For example, the A-term Ax.x corresponds to the action process lam((a;)(a;)), 
which illustrates the use of abstracted datums. Again we do not permit reaction 
inside a lam-control. The reaction relation is generated by the two rules 

(lam(P) I idi) • ap \ P 
(lam(P) I id^).(a;)Q \ Q{\am{P)/{x)}. 

The first axiom describes /3-reduction, and the second describes the explicit 
substitution of a lam-process for abstracted datums. In fact, there is a higher- 
order extension of action calculi where the lam- and ap-controls are regarded as 
primitive constructs. The details can be found in [Mil94a,HG97]. 

There is another extension of the action calculus framework [Mil94b], which 
includes a reflexion (or feedback) operator 

P : (to -I- 1, n -I- 1) 

"[P : (to, n) 

The reflexion operator does not have a direct analogy in the 7r-calculus. It does 
have a direct analogy in the A-calculus, in that the A„ action calculus plus 
reflexion corresponds to the cyclic A-calculus of Ariola and Klop [Has97]. The 
reflexion axioms correspond to adding a trace operator [.JSV96] to the symmetric 
monoidal category. We do not concentrate on the reflexive extension here, since 
our aim is to illustrate the close connection between the 7r-calculus and the action 
calculus framework. It is however of fundamental importance. In particular, the 
recent bisimulation results of Leifer and Milner rely on this extension. 

Leifer and Milner are currently exploring general bisimulation results for 
(simple) reactive systems [LMOO], and aim to extend their results to a class of 
reflexive action calculi. Such results have also been studied by Sewell [SewOO]. 
The idea is to automatically generate a labelled transition system from an under- 
lying reaction relation, and yield a corresponding bisimulation congruence. The 
labelled transitions have the form P — > Q, with the intuition that C is a small 
context necessary to complete a redex in P. Leifer and Milner have characterised 
what it means for these small contexts to exist. Their challenge is to show that 
they do indeed exist for specific reactive systems such as action calculi. 

3 The TTf-Calculus 

In this section, we describe the 7Ti?-calculus and define a natural bisimulation 
congruence. The 7Ti?-calculus is similar in many respects to the fusion calculus 
of Parrow and Victor [PV98], and the y-calculus of Fu [Fu97], although we 
did not invent the Tr^-calculus with these connections in mind. There is no 
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abstraction. Instead, the TTii’-calculus has symmetric input and output processes, 
with a reaction relation which fuses the names together using explicit fusions. 
An explicit fusion {z = y) is a, process which declares that two names can be used 
interchangeably. 

The key difference between the TTi^’-calculus and the fusion calculus is how the 
name- fusions have effect. In the TTiT’-calculus, fusions are explicitly recorded and 
have effect though the structural congruence. For example, a typical 7Ti?-reaction 
is 



x.{z)P\x.{y)Q\R \ {z = y)\P\Q\R. 

The explicit fusion {z = y) declares that z and y can be used interchangeably 
throughout the process. The reaction on the channel a; is a local one between 
the input and output processes. However, its effect is global in that the scope 
of {z = y) affects process R. The scope of an explicit fusion is limited by the 
restriction operator. In the fusion calculus on the other hand, fusions occur 
implicitly within the reaction relation. For example, the fusion reaction 

{vy){x.{z)P I x.{y)Q \ R) \ P{z/y} \ Q{z/y} \ R{z/y} 

corresponds to the restriction (with respect to y) of the TTi^-reaction given above. 
This fusion reaction is not a simple local reaction between input and output 
processes. Instead, the redex is parametrized by R and requires y (or z) to be 
restricted. The full definition, using many ys and is, is in fact quite complicated. 

Definition 5 

The set V' of pre-processes of the TTi^’-calculus is defined by the grammar 



nil 


Nil process 


P\P 


Parallel composition 


P@P 


Connection 


(x) 


Datum 


{x = y) 


Fusion 


{vx)P 


Restriction 


x.P 


Input Process 


X.P 


Output process 



The definitions of free and bound names are standard. The restriction operator 
{ux)P binds x] otherwise x is free. The connection operator is used to connect 
the contents of input and output processes during reaction: 

x.P I x.Q \ P@Q. 

We regard the connection operator as primitive. However, we shall see that it 
can be derived from the other axioms. It can also be derived in the fusion system 
framework, so our choice to include it is really not essential. 

To define reaction properly, we require the correct number of datums in P 
and Q to connect together. This information is given by the arity of a pre-process. 
We write P : m to declare that a pre-process has arity m, where m is a natural 
number used to count datums. 
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Definition 6 

The set of processes of the 7Ti?-calculus with arity m is defined inductively 
by the rules 

nil : 0 {x = y) : 0 (x) : 1 

P \ m Q : n P : m Q : m P : m 

P\Q ■. m + n P@Q : 0 {vx)P : m 

P \ m P : m 

x.P : 0 x.P : 0 



Definition 7 

The structural congruence between processes, written =, is the smallest congru- 
ence satisfying the axioms given in figure 3, and which is closed with respect to 
_ I {vx)- , X.- and x._. 

The side-condition on the commutativity of parallel composition allows for 
processes of arity 0 to be reordered, but not arbitrary processes. The connection 
axioms are simple. 

The fusion axioms are similar in spirit to the name-equalities introduced 
by Honda in his work on a simple process framework [HonOO]. Our intuition 
is that {x = y) is a symmetric relation which declares that two names can be 
used interchangeably. The fusion (x = x) is congruent to the nil process. So too 
is {vx){x = y), since the local name is unused. Notice that the standard axiom 
(i^a;)nil = nil is derivable from these two fusion axioms. The other six fusion 
axioms describe small-step substitution, allowing us to deduce {x = y)\P = 
{x = y) \ P{x/y} as well as a-conversion. For example, 

{vx){x.n\\) 

= iyx){vy){{x = y) \ x.nW) create fresh local name y as an alias for x 

= {ux){vy){{x = y) \y.n\\) substitute y for a; 

= {iyy){y.n\\) remove the now-unused local name x 

Just as for the 7r-calculus, a property of the structural congruence is that 
every Tr^-process is structurally congruent to a standard form. Standard forms 
are processes with the shape 



(i/f)((y) |P) I {u = v), 

where the xs are distinct and contained in the ys, and P : 0 does not contain 
connections or fusions. The standard form is essentially unique in the sense that, 
given two congruent standard forms 

(l^fl)((yi) I Pi) I {ui=Vl) = {VX2){{V2) IP2) I {u2=V2), 

then |afi| = |i 2 |, the fusions {u\ = vi) and {u 2 = V 2 ) generate the same equiva- 
lence relation on names, the yi and 2/2 are the same up to a-conversion of the alis 
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Standard axioms for (vx)- and nil: 

P| nil P 

(p|Q)|p = p|(g|p) 

P I g = Q I P, P : 0 

[vx){vy)P = {vy){vx)P 
{vx){P\Q) = {vx)P\Q, X 0 fn(g) 

(i/x)(P I g) = P I (i/x)g, X ^ fn(P) 

Connection axioms: 

(i'x){P@Q) = {i'x)P@Q, X ^ fn(g) 

{vx){P@Q) = P@{vx)Q, X ^ fn(P) 

((x)|P)@((j/)|g) = (x=t/)|(p@g) 
p@g = p\Q, p, g : 0 

Fusion axioms: 

(x = x) = nil (x = y) I y.P = (x = y) | x.P 

(x = y) = {y = x) (x = y) I y.P = (x = y) |x.P 

[vx){x = y) = nil {x = y)\{y = z) = {x = y) \ {x = z) 

{x = y)\ {y) = {x = y}\ (x) 

(x = y) I z.P = (x = y) I z.{{x = y)\P) 

(x = y) I z.P = (x = y) I z.{{x = y) | P) 

Fig. 3. The structural congruence between 7Ti:’-processes of the same arity, writ- 
ten =, is the smallest equivalence relation satisfying these axioms and closed 
with respect to contexts. 

and X 2 S, and up to the name-equivalence generated by fusions, and Pi and P 2 
are structurally congruent up to a-conversion and the name-equivalence. We 
write E{P) for the smallest equivalence relation on names generated by P. This 
equivalence relation can be inductively defined on the structure of processes; a 
simple characterisation is given by (x, y) G E{P) if and only if P = P\{x = y). 

Using the standard forms, it is possible to express the connection operator 
as a derived operator. 

Definition 8 

The reaction relation between TTi^-processes of the same arity , written \, is the 
smallest relation generated by 

x.P I x.Q \ P@Q, 

where P and Q have arity m and the reaction is closed with respect to _ | _, 
(i^x)_ and _ = _. 
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3.1 Bisimulation Congruence 

A natural choice of labelled transition system (LTS) for the 7ri?-calculus consists 
of the usual CCS-style transitions using labels x, x and r, accompanied by a 
definition of bisimulation which incorporates fusions: PSQ : 0 implies 

for all X and y, ii P \ {x = y) P\ then Q\{x = y) Q\ and 

We call this bisimulation the open bisimulation, since it is similar to the open 
bisimulation of the 7r-calculus. 

In the definition of open bisimulation, labelled transitions are analysed with 
respect to the fusion contexts _| (x = y). In fact, we do not need to consider all 
such contexts. Instead, we introduce the fusion transitions, generated by the 
axiom 

x.P\y.Q'^ P@Q. 

A fusion transition with label lx = y declares the presence of input and out- 
put processes with channel names x and y, although we do not know which 
name goes with which process. The resulting bisimulation definition is simpler, 
in that it is enough to analyse the fusion transitions rather than consider all 
fusion contexts. However, these fusion transitions do seem to provide additional 
information about the structure of processes. In order to define a bisimulation 
relation which equals the open bisimulation, we remove this information in the 
analysis of the labelled transitions: PSQ : 0 implies 

if P 'd— F Pi then either Q Q\ or Q Qi, and P\ \ {x = y) S Q\ \ {x = y). 

A consequence of adding fusion transitions is that we can use standard techniques 
to show that the resulting bisimulation relation is a congruence, and does indeed 
equal the open bisimulation. 

In [GWOO], we also study the more standard definition of bisimulation, which 
requires that fusion transitions match exactly. We know it yields a congruence 
which is contained in the open bisimulation. At the moment, we do not know 
whether the containment is strict. This question relates to an open problem for 
the TT-calculus without replication and summation of whether strong bisimu- 
lation is closed with respect to substitution. 

The fusion LTS is given in figure 4. The labelled transitions follow the style 
of transition given in [Mil99], although our transitions are defined for arbitrary 
processes instead of processes of arity 0. This choice is not essential, since the 
bisimulation definition only refers to labelled transitions for processes of arity 0. 
The only additional complexity is that we have two rules for parallel composition, 
since this operator is only commutative for processes of arity 0. Notice that the 
structural congruence rule allows fusions to affect the labels: for example, the 

process (x = y) \x.P can undergo the transition — ^ as well as because it 
is structurally congruent to {x = y) \y.P. Also notice that we do not have an 
explicit structural rule for the connection operator. Indeed, it is not possible to 
write such a rule, since the arity information would cause problems. 

^ Personal communication with Davide Sangiorgi. 
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X.P P 


X.P P 


X.P 


\y.Q-^P@Q 


X.P 1 x.Q — ^ P@Q 




P Pi 


Q^Qi 


p 


\Q^Pi\Q 


P\Q^P\Qi 


P Q, X ^ a 


P = Pl^Ql=Q 



{vx)P {vx)Q P Q 



Fig. 4. The labelled transition system for arbitrary 7ri?-processes. We do not 
distinguish between the labels 7x = y and ly = x. 

Proposition 9 
P \ Q if and only if P Q. 

The basic intuition regarding our definition of bisimulation is that two pro- 
cesses are bisimilar if and only if their standard forms have the same outer 
structure and, in all contexts of the form -@{y), if one process can do a labelled 
transition then so must the other to yield bisimilar processes. In fact, we do not 
need to consider all such contexts. Instead, it is enough to remove the top-level 
datums from the standard forms, and analyse the labelled transitions for the 
resulting processes. 

Definition 10 (Fusion Bisimulation) 

A symmetric relation S' is a fusion bisimulation if and only if PSQ implies 

1. P and Q have standard forms {vx){{y) |Pi) | {u = v) and {vx){{y) \ Qi) \ 
(u = v) respectively; 

2a. if Pi I {u = v) P[ where a\s x,x or t then Qi\[u = v) Q'l and P(SQi; 
2b. if Pi I (u = v) P[ then either Qi\{u = v) Q\ or Q\ \ {u = v) — ^ Q[ 
and P{ I {x = y)SQ[ \ {x = y); 

3. similarly for Q. 

Two processes P and Q are fusion bisimilar, written P Q, if and only if there 
exists a fusion bisimulation S between them. The relation ~/ is the largest fusion 
bisimulation. We call it the fusion bisimulation, when the meaning is apparent. 

This definition of fusion bisimulation is related to Sangiorgi’s efficient character- 
isation of open bisimulation for the 7r-calculus with matching [San93] . 

The fusion transitions enable us to use standard techniques for proving that 
the fusion bisimulation is a congruence. We remove the structural congruence 
rule, and define an alternative LTS based on the structure of processes. This 
alternative LTS is given in figure 5. The non-standard rules are the fusion rules. 
The first two play a similar role to the r-rules for the 7r-calculus. The other two 
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x.P P 



x.P P 



P^Pi Q-^Qi 

P\Q'^ Pi@Qi 

P^Q {x,y)GE{P) 
P g 

P Pi 
P\Q^ Pi \Q 

P g, X ^ a 
{vx)P {vx)Q 



P^Pi Q-^Qi 
P\q''^ Pi@Qi 

P Q 
P^Q 

Q^Qi 

P\Q^P\Qi 



Fig. 5. The alternative LTS for arbitrary processes. The judgement a[y/x] de- 
notes the simple substitution of one y for one x, generated by: x[y/x] = y; 
x[y/x\ = y] {lx = z)[y/x\ =ly = z, and a[y/x\ = a when x ^ a. Recall that 
E{P) is the smallest equivalence relation on names generated by P. 



express the effect of explicit fusions on labels and the generation of r-transitions 
from simple fusion transitions. Notice that we have no rules for the connection 
operator. The connection between the fusion LTS and the alternative LTS is 
therefore only valid up to structural congruence. 

Using the alternative LTS, we are able to define a bisimulation relation, 
prove that it is a congruence and show that it equals the fusion bisimulation. 
The details are given in [GWOO]. With this congruence result, it is not difficult 
to show that fusion bisimulation equals open bisimulation. 



4 Fusion Systems 

The fusion system framework consists of the same basic process constructs as the 
TTir-calculus. It generalises the input and output processes to more general control 
processes. For action calculi, control processes have the form K{Pi, . . . ,Pr). It 
is possible to use the same approach for fusion systems. Instead, we choose to 
focus on control processes of the form x.K{Pi, . . . ,Pr), where the control K is 
a boundary containing the processes Pi and the names x provide the interface 
to the control. With this choice of control process, the connection operator can 
be derived from the other operators. 

A fusion calculus is specified by a set K. of controls, and a reaction relation 
describing the interaction between controls. Each control AT in /C has an asso- 
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dated arity (mi, . . . ,mr) — ^ k. The arity tells us how to construct a control 
process x.K{Pi, . . . ,Pr), where the rrii specify the arities of the Pi and |i| = k. 

Definition 11 

The set Vf{IC) of pre-processes of a fusion system specified by control set JC is 
defined by the grammar 



P 



nil 

P\P 

P@P 

(x) 

{x = y) 

{vx)P 

,P,) 



Nil process 

Parallel composition 

Connection 

Datum 

Fusion 

Restriction 

Control process 



The set VpiJC) of fusion processes with arity m is defined by the rules in defini- 
tion 6, with the input and output rules generalised to the control rule 

Pj : m* i € {1, . . . ,r} 
f.lF(Pi,... ,Pr):0 



where control K has arity (mi, . . . , rrir) —>■ k and |al| = k. 

The definitions of free and bound names are standard. The definition of the 
structural congruence between fusion processes is the same as that given for the 
TTir-calculus in figure 3, except that it is closed with respect to arbitrary control 
processes. The standard forms are defined in the same way as those for the np- 
calculus given in section 3. We can therefore derive the connection operator from 
the other operators. The reaction relation \ is a binary relation between fusion 
processes of the same arity, which is closed with respect to _ | , (i^a;)_ and 
_ = _. We are able to specify whether the reaction relation is closed with respect 
to the controls. 



The 7T Fhsion System We define the tt fusion system, which is just a refor- 
mulation of the TTiT’-calculus. It is specified by the controls 

in : (m) — > 1 out : (m) — > 1 

where the TTi^-processes x.P and x.P correspond to the control processes of the 
form a;.in(P) and a;.out(P) respectively. The reaction relation is generated by 
the rule 



a;.in(P) | a;.out((5) \ P@Q, 

where P and Q have the same arity and reaction does not occur inside the 
controls. Since the correspondence with the 7ri?-calculus is exact, the bisimulation 
results described in section 3.1 easily transfer to the wp fusion system. 
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We summarise the embedding results of the 7r-calculus and the fusion calculus 
in the np fusion system. These results follow immediately from the analogous 
embeddings in the TTi^’-calculus [GWOO]. The translations of the 7r-calculus and 
the fusion calculus into np fusion system are characterised by the input and 
output cases described above, plus the abstraction and concretion cases: 

|(ai)P] = {vx){{x) I |P]) Abstraction 

\{vx){^p\ = {iyx){{^ I |P]) Concretion 

There is a key difference between the embedding of the 7r-calculus and the em- 
bedding of the fusion calculus. For the 7r-embedding, reaction of a process in the 
image of |_] necessary results in a process congruent to one in the image. The 
same is not true with the embedding of the fusion calculus, since for example 

x.in((z) ||P]) |a;.out((?/) IIQl) \ (z = y) ||P] ||Q] , 

which does not have a corresponding reaction in the fusion calculus. The process 
on the left is in the image of the fusion calculus under |_], but the one on the 
right has an unbound explicit fusion and so is not congruent to anything in the 
image. We do obtain an embedding result, in that by restricting y (or z) we 
obtain the irp fusion reaction 

{iyy){x.\n{{z) I |P]) I a;.out((y) | |Q])) \ {iyy){{z = y) \ |P] | |Q]) 

= lP\{z/y}\{Q\{z/y}, 



which does indeed correspond to a fusion reaction. The full translations and 
embedding results are given for the 7Ti?-calculus in [GWOO]. 



The Fhsion System We define the A„ fusion system, which corresponds to 
a call- by- value A-calculus. It is also possible to define fusion systems for the usual 
untyped A-calculus, and the simply-typed versions by adding more structure to 
the arities. These fusion systems require the ability to replicate processes, which 
we have not used before. We are currently checking that our bisimulation results 
in section 3.1 hold in the presence of replication. We do not envisage difficulties. 

The A„ fusion system is specified by the controls 

lam : (2) ^ 1 ap :()—*■ 3. 

The idea is that the untyped A-terms correspond to processes of arity 1. A lam- 
process of the form u.lam(P) ‘locates’ the function at u, with the extra arity 
for the process P corresponding to the abstraction of the A-term. An ap-control 
uuw.ap ‘locates’ its function at u, its argument at v and its result at w. The 
reaction relation is generated by 



u.lam(P) I uvw. ap \ P@{vw). 
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and reaction does not occur inside the lam-control. The translation from lambda 
terms to fusion processes is defined inductively by 

M ' — > (x) 

lAx.t] I — > (i^u)((u) I !M.lam((j/a;)((a;) ||t]))) m ^ fn(|Aa;.t]) 

1st] I — > (j^ur;r(;)((r(;) I |s]@(m) I |t]@(v) I Mz;w.ap) u, z;, w ^ fn(|st]) 

The replication in the translation of the lambda abstraction is used to generate 
copies of lambda processes via the structural congruence. 

The results for the call-by-value A-calculus are not as straightforward as 
the results for the TTp-example. To illustrate this, consider the lambda reaction 
{\x.x)y \ y which corresponds to the fusion system reaction 

{vuw){{w) I \u.{{vx){xx)) \ u.{{yw))) \ {y) \ {vu){\u.{{vx){xx))). 

After reaction, the process {vu)(lu.{{vx){xx))) is redundant. This redundancy 
is expressed by a bisimulation congruence, with the process {iyu)(\u.((v'x){xx))) 
bisimilar to nil. Bisimulation is thus required to relate the reaction relation of 
the A-calculus with reaction in the Xy fusion system. 

Bisimulation for the Xy fusion system is easy. It follows directly from bisim- 
ulation for the TTp fusion system. This is because the Ai, fusion system can be 
regarded as a simple subsystem of the np fusion system, using the translation 

|M.lam(P)l M.in([P]) 

luzzw.ap] M.out((?;r(;)) 

which trivially preserves the reaction relation. It is future work to show whether 
the resulting congruence corresponds to a known behavioural congruence for the 
call-by-value A-calculus. 

It also remains future work to study general bisimulation congruences for 
fusion systems. One option is to try to generalise the bisimulation results for 
the TTp and A„ fusion systems. Another option is to adapt the techniques of 
Leifer and Milner, in their work on general bisimulation congruences for reactive 
systems [LMOO]. However, this is not our primary concern. We would first like 
to explore specific examples of fusion systems to illustrate the expressive power 
of explicit fusions. 
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1 Abstract 

The LMC project aims to advance the state of the art of system specification 
and verification using the latest developments in logic programming technol- 
ogy [CDD+98]. Initially, the project was focussed on developing an efficient 
model checker, called XMC [RRR+OT], for value-passing CCS [Mil89] and the 
modal mu-calculus [Koz83] based on the XSB logic programming sys- 
tem [XSBOO]. We developed an optimizing compiler to translate specifications 
in a dialect of value-passing CCS to compact labeled transition systems [DR99], 
improving verification performance several fold. The core principles of this trans- 
lation have been recently incorporated in SPIN [Hol97] showing similar gains in 
performance [Hol99]. The XMC system can be downloaded from 
http : //www . cs . sunysb . edu/~lmc. 

More recently, we have developed 

— techniques using logic-program transformations [TS84,PP99,RKRR99] for 
verifying parameterized systems, i.e., infinite families of finite-state systems 
[RKR+00]; 

— a proof-tree viewer for justifying successful or failed verification runs for 
branching-time properties [RRROO]; 

— a symbolic bisimulation checker (based on the work of [HL95]) for value- 
passing systems [MRRVOO]; 

— model checkers for 

• real-time systems [DRSOO] based loosely on the local model checking 
algorithm of [SS95] ; 

• LTL with actions [PROO] based on GCTL* of [BCGOO] and the on-the-fly 
model checking algorithm in [BCG95]; 

In this tutorial, we describe the XMC system as well as the above develop- 
ments. In addition, we outline the research efforts of the verification and the logic 
programming community that have been instrumental in these developments. 

* Research supported in part by NSF grants EIA-9705998, CCR-9711386, CCR- 
9805735, and CCR-9876242. 
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